openVswitch（OVS）源代码分析之工作流程（哈希桶结构体的解释）
最后更新于：2022-04-01 07:42:36
这篇blog是专门解决前篇[openVswitch（OVS）源代码分析之工作流程（哈希桶结构体的疑惑）](http://blog.csdn.net/yuzhihui_no1/article/details/39558815)中提到的哈希桶结构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](http://blog.csdn.net/yuzhihui_no1/article/details/39939241)
分析得比较匆促，若有不正确之处，望大家指正，共同学习！谢谢！！！