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

        分析得比較匆促，若有不对之处，望大家指正，共同学习！

谢谢。！

！