linux3.10gro的理解和改进

gro&＃xff0c;将同一个flow的一定时间范围之内的skb进行合并&＃xff0c;减少协议栈的消耗&＃xff0c;用于收包性能提升。gro网上的资料很多&＃xff0c;但是都很少谈到gro的改进&＃xff0c;刚好身边有个同事也想改这块的内容&＃xff0c;

所以将最近看的gro内容总结一下&＃xff0c;作为记录。

gro的层次&＃xff0c;很少有资料提到&＃xff0c;可能是大牛们觉得太简单&＃xff0c;但我还是记录一下&＃xff0c;毕竟我基础不好。

 先看关键的数据结构&＃xff0c;然后分析流程&＃xff1a;

为了在skb中记录相关的gro信息&＃xff0c;使用了skb的cb字段。

48字节的cb字段&＃xff0c;被用完了。

所有的packet 级别的gro的类型&＃xff0c;放在一个公共链表头 offload_base 变量中管理&＃xff0c;我测试的系统中的packet级别的gro类型有&＃xff1a;

所有的inet层的gro回调&＃xff0c;都存储在inet_offloads 数组中&＃xff0c;根据当前加载的模块&＃xff0c;本机器对应支持的gro就有&＃xff1a;

gro的调用查找过程如下&＃xff1a;

从dev层&＃xff0c;根据到来的skb&＃xff0c;可以根据skb->protocol 作为type的类型&＃xff0c;比如type是 .type &＃61; cpu_to_be16(ETH_P_IP),然后才会进入 ip_packet_offload 这个层次&＃xff0c;

在 offload_base这个链表头找到对应的type&＃xff0c;然后获取对应的callback.gro_receive 函数。

找到了对应的inet_gro_receive&＃xff0c;就进入了packet层&＃xff0c;那么根据iph->protocol&＃xff0c;就在 net_offload 数组中&＃xff0c;找到对应协议类型的gro结构&＃xff0c;比如找到的是 tcpv4_offload。

那么针对tcp的gro&＃xff0c;其i40e驱动的调用顺序就是&＃xff1a;

i40e_napi_poll--->|i40e_clean_tx_irq

                        --->|i40e_clean_rx_irq-->napi_gro_receive-->dev_gro_receive-->inet_gro_receive-->tcp4_gro_receive

对应的堆栈如下&＃xff1a;

 当然&＃xff0c;根据作者的注释&＃xff0c;与其将这8改大&＃xff0c;不如改成一个hash表&＃xff0c;不同的skb先哈希到一个flow链&＃xff0c;然后在链中比较看能否合并&＃xff0c;这样对于gro流程需要改动为&＃xff1a;

1.创建flow的hash表&＃xff0c;让skb中看到flow&＃xff0c;然后在flow的冲突链中找对应的gro_list&＃xff0c;然后看能否合并。

2.percpu模式&＃xff0c;不适用napi_struct来管理gro_list.

3.修改合并条件&＃xff0c;比如对于tcp的ack来说&＃xff0c;目前不带数据的ack无法合并&＃xff0c;因为才54个字节&＃xff0c;而以太网发出的时候会填充&＃xff0c;导致不满足如下条件&＃xff1a;

但对于流媒体服务器来说&＃xff0c;纯ack占入向的比例很高&＃xff0c;需要将条件改动&＃xff0c;由于ack还涉及到快发流程的进入和退出&＃xff0c;所以ack合并还是有一些工作要做的。

4.修改间隔&＃xff0c;目前限制死了是一个jiffies&＃xff0c;比如服务器8M左右的发送码率&＃xff0c;收到的ack间隔可以释放放大&＃xff0c;不然合并几率也比较低&＃xff0c;当然这个是以tcp的send_buf中的数据占用更多内存为前提的。

   所以需要一个导出到/proc文件系统的间隔字段来控制。

5.对于低速发送码率的服务器来说&＃xff0c;可以关闭gro&＃xff0c;对于lvs服务器来说&＃xff0c;应该关闭gro。