openVswitch(OVS)源码分析之工作流程(哈希桶结构体的解释)

Posted gavanwanggw

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了openVswitch(OVS)源码分析之工作流程(哈希桶结构体的解释)相关的知识,希望对你有一定的参考价值。

        这篇blog是专门解决前篇openVswitch(OVS)源码分析之工作流程(哈希桶结构体的疑惑)中提到的哈希桶结构flex_array结构体成员变量含义的问题。

        引用下前篇blog中分析讨论得到的flex_array结构体成员变量的含义结论:

struct {  
            int element_size; // 这是flex_array_part结构体存放的哈希头指针的大小  
            int total_nr_elements; // 这是全部flex_array_part结构体中的哈希头指针的总个数  
            int elems_per_part; // 这是每一个part指针指向的空间能存储多少个哈希头指针  
            u32 reciprocal_elems;   
            struct flex_array_part *parts[]; // 结构体指针数组。里面存放的是struct flex_array_part结构的指针  
        };  
        事实上这个结论是正确的,这些结构体成员的含义就是这些意思。但前篇分析中这个结论和static inline int elements_fit_in_base(struct flex_array *fa)函数产生矛盾。这里也看下该函数的详细实现:

static inline int elements_fit_in_base(struct flex_array *fa)  
{  
// fa->element_size 依据上面的结论应该是哈希头的大小,flex_array_part结构体中存放的哈希头大小  
// fa->total_nr_elements 依据上面的结论应该是全部哈希头的总数  
// 那么data_size 就是全部存储哈希头的空间大小了,矛盾来了  
    int data_size = fa->element_size * fa->total_nr_elements;  
// FLEX_ARRAY_BASE_BYTES_LEFT是什么意思呢?  
// #define FLEX_ARRAY_BASE_BYTES_LEFT  (FLEX_ARRAY_BASE_SIZE - offsetof(struct flex_array, parts))  
// offsetof()宏用来求一个成员在结构体中的偏移量  
// 所以全部存储哈希头空间的大小和 FLEX_ARRAY_BASE_BYTES_LEFT 比較是什么意思呢?
// 我当时的推断就是element_size和total_nr_elements这两个成员变量理解错了。

if (data_size <= FLEX_ARRAY_BASE_BYTES_LEFT) return 1; return 0; }

        假设依照一般的思想来分析这个源码真的有问题了,至少这个函数分析不下了。那么真正的原因是什么呢?

        首先来看下哈希桶内存申请函数(在上篇中有分析)当中传过来的分别为:elements = sizeof(struct hlist*)和total = 1024(宏定义而来)。

        再看看上面这个函数的实现:data_size = element_size * total_nr_elements; 也即是 data_size = elements * total;带入数据得:data_size = 4 * 1024 = 4096(由于两个參数一个是宏定义的。对整个项目来说是不变的;另外一个也一样是不会变的。所以能够当做常量带入去应验下);

        那么如今来看看if推断语句:data_size <= (4096 - 4*4)。由于依据上面的flex_array结构体成员变量能够知道:有3个int型成员和一个u32类型的成员。

所以得到parts前有 4*4个字节。用一个页的大小减去到parts成员前的字节为:4096 - 4*4。

        最后把全部数据带入能够得到:4096 <= (4096 - 4*4);那么这个条件肯定是恒不成立的。所以这个函数就是多余的了,由于data_size的值是一定为4096的。无论flex_array结构中成员变量代表什么意思。而FLEX_ARRAY_BASE_BYTES_LEFT也是一定不变的。

        得到上面的结论事实上离真相就比較接近了,能够想象得到一个由这么多顶尖的程序猿设计出来的项目,不太可能会出现一个冗余的函数。并且在flex_array.c中大量的使用。那么这个函数一定有其它用处,我想了非常多种可能,也重复的分析flex_array.c和flex_array.h中的源码,最后我得到一种猜想:就是当这个项目中所要的最大元素数非常小。就是说依据需求total不须要1024。不要那么大呢? 

        猜想:须要的流表项链表头结点比較少(total_nr_elements < 1024)。那么不须要分配一个parts指针(一个parts数组指针元素有一个页大小的空间)来存储。假设total_nr_elements不大于1020,就不是必需分配parts指针了。直接在flex_array结构体(该结构体的大小为一个页,有3个int型和1个u32成员,所以剩下的就是1020 * 4个字节了)中存储就得了。

        以下来验证下这个猜想,来分析调用了static inline int elements_fit_in_base(struct flex_array *fa)函数的各个代码:

if (elements_fit_in_base(fa))
		part = (struct flex_array_part *)&fa->parts[0];
else {
		part_nr = fa_element_to_part_nr(fa, element_nr);
		part = __fa_get_part(fa, part_nr, flags);
		if (!part)
			return -ENOMEM;
	}
        这段代码在非常多函数中都有。能够看int flex_array_put(struct flex_array *fa, unsigned int element_nr, void *src,gfp_t flags);数据拷贝函数的详细实现。该代码中调用了elements_fit_in_base(fa)来推断,假设成立。也就是说total_nr_elements不大于1020;那么直接用数组头元素的地址来强转为须要的结构体。即是直接在数组头元素存储的地方開始操作,而不是数组头元素指向的地方開始操作。说明了数据就是存储在flex_array结构体中。

        以下来看另外一段代码:

void flex_array_free_parts(struct flex_array *fa)
{
	int part_nr;

	if (elements_fit_in_base(fa))
		return;
	for (part_nr = 0; part_nr < FLEX_ARRAY_NR_BASE_PTRS; part_nr++)
		kfree(fa->parts[part_nr]);
}
         看这段代码大概就知道是用来释放parts内存的。该代码中调用了elements_fit_in_base(fa),假设成立。也就是说total_nr_elements不大于1020;那么就直接返回,什么都不运行。

这就暗示了这个项目中根本就没有申请parts内存,全部的流表项链表头结点都是存放在flex_array结构体中的。

再看下行的for循环,是从0開始的,更能说明假设total_nr_elements大于1020就一定得申请parts内存。

        还有其它代码中调用了该函数,就不一一列证了。

就眼下为止来说这个猜想还是比較符合源码的。我不能百分百的说这个猜想是正确的。希望有兴趣的朋友能够分析下。

当然我也在找各种途径去分析这个矛盾和猜想。 

        转载请注明作者和原文出处,原文地址:http://blog.csdn.net/yuzhihui_no1/article/details/39939241
        分析得比較匆促,若有不对之处,望大家指正,共同学习!

谢谢。!


以上是关于openVswitch(OVS)源码分析之工作流程(哈希桶结构体的解释)的主要内容,如果未能解决你的问题,请参考以下文章

[ovs] openvswitch 从源码编译安装

OpenvSwitch系列之ovs-vsctl命令

openvswitch源码 从哪个文件开始看

Openvswitch原理与代码分析: ovs-vswitchd的启动

Openvswitch原理与代码分析: ovs-vswitchd的启动

Openvswitch原理与代码分析:总体架构