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内存。
还有其它代码中调用了该函数,就不一一列证了。
就眼下为止来说这个猜想还是比較符合源码的。我不能百分百的说这个猜想是正确的。希望有兴趣的朋友能够分析下。
当然我也在找各种途径去分析这个矛盾和猜想。
谢谢。!
!
以上是关于openVswitch(OVS)源码分析之工作流程(哈希桶结构体的解释)的主要内容,如果未能解决你的问题,请参考以下文章
Openvswitch原理与代码分析: ovs-vswitchd的启动