gro，将同一个flow的一定时间范围之内的skb进行合并，减少协议栈的消耗，用于收包性能提升。gro网上的资料很多，但是都很少谈到gro的改进，刚好身边有个同事也想改这块的内容，
所以将最近看的gro内容总结一下，作为记录。
gro的层次，很少有资料提到，可能是大牛们觉得太简单，但我还是记录一下，毕竟我基础不好。
先看关键的数据结构，然后分析流程：
为了在skb中记录相关的gro信息，使用了skb的cb字段。
crash> napi_gro_cb
struct napi_gro_cb {
void *frag0;
unsigned int frag0_len;
int data_offset;
u16 flush;
u16 flush_id;
u16 count;
u16 gro_remcsum_start;
unsigned long age;
u16 proto;
u8 encap_mark : 1;
u8 csum_valid : 1;
u8 csum_cnt : 3;
u8 is_ipv6 : 1;
u8 free : 2;
u8 same_flow : 1;
u8 recursion_counter : 4;
u8 is_atomic : 1;
__wsum csum;
struct sk_buff *last;
}
SIZE: 48
48字节的cb字段，被用完了。
所有的packet 级别的gro的类型，放在一个公共链表头 offload_base 变量中管理，我测试的系统中的packet级别的gro类型有：
crash> list packet_offload.list -H offload_base -s packet_offload ffffffff81b41bc0 struct packet_offload { type = 8, priority = 0, callbacks = { gso_segment = 0xffffffff816155b0 <inet_gso_segment>, gro_receive = 0xffffffff816159a0 <inet_gro_receive>, gro_complete = 0xffffffff816148c0 <inet_gro_complete> }, list = { next = 0xffffffff81b43b40 <ipv6_packet_offload+32>, prev = 0xffffffff81b3f0e0 <offload_base> } } ffffffff81b43b20 struct packet_offload { type = 56710, priority = 0, callbacks = { gso_segment = 0xffffffff8168c670 <ipv6_gso_segment>, gro_receive = 0xffffffff8168c300 <ipv6_gro_receive>, gro_complete = 0xffffffff8168c120 <ipv6_gro_complete> }, list = { next = 0xffffffff81b3f7c0 <eth_packet_offload+32>, prev = 0xffffffff81b41be0 <ip_packet_offload+32> } } ffffffff81b3f7a0 struct packet_offload { type = 22629, priority = 10, callbacks = { gso_segment = 0x0, gro_receive = 0xffffffff815bbd60 <eth_gro_receive>, gro_complete = 0xffffffff815bbbe0 <eth_gro_complete> }, list = { next = 0xffffffff81b3f0e0 <offload_base>, prev = 0xffffffff81b43b40 <ipv6_packet_offload+32> } }
所有的inet层的gro回调，都存储在inet_offloads 数组中，根据当前加载的模块，本机器对应支持的gro就有：
p inet_offloads inet_offloads = $48 = {0x0, 0x0, 0x0, 0x0, 0xffffffff8176fd80 <ipip_offload>, 0x0, 0xffffffff8176f220 <tcpv4_offload>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff8176f560 <udpv4_offload>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff81777680 <sit_offload>, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff81770be0 <gre_offload>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 。。。。 0x0, 0x0, 0x0}
gro的调用查找过程如下：
从dev层，根据到来的skb，可以根据skb->protocol 作为type的类型，比如type是 .type = cpu_to_be16(ETH_P_IP),然后才会进入 ip_packet_offload 这个层次，
在 offload_base这个链表头找到对应的type，然后获取对应的callback.gro_receive 函数。
找到了对应的inet_gro_receive，就进入了packet层，那么根据iph->protocol，就在 net_offload 数组中，找到对应协议类型的gro结构，比如找到的是 tcpv4_offload。
那么针对tcp的gro，其i40e驱动的调用顺序就是：
i40e_napi_poll--->|i40e_clean_tx_irq
--->|i40e_clean_rx_irq-->napi_gro_receive-->dev_gro_receive-->inet_gro_receive-->tcp4_gro_receive
对应的堆栈如下：
[root@localhost caq]# stap -d i40e netif_rx.stp System Call Monitoring Started (10 seconds)... WARNING: DWARF expression stack underflow in CFI 0xffffffff816041a0 : tcp4_gro_receive+0x0/0x1b0 [kernel] 0xffffffff81615be9 : inet_gro_receive+0x249/0x290 [kernel] 0xffffffff815951b0 : dev_gro_receive+0x2b0/0x3e0 [kernel] 0xffffffff815955d8 : napi_gro_receive+0x38/0x130 [kernel]-------------gro处理开始 0xffffffffc01f4bde : i40e_clean_rx_irq+0x3fe/0x990 [i40e] 0xffffffffc01f5440 : i40e_napi_poll+0x2d0/0x710 [i40e] 0xffffffff81594cf3 : net_rx_action+0x173/0x380 [kernel] 0xffffffff8109404d : __do_softirq+0xfd/0x290 [kernel] 0xffffffff816c8afc : call_softirq+0x1c/0x30 [kernel] 0xffffffff8102d435 : do_softirq+0x65/0xa0 [kernel] 0xffffffff81094495 : irq_exit+0x175/0x180 [kernel] 0xffffffff816c9da6 : __irqentry_text_start+0x56/0xf0 [kernel] 0xffffffff816bc362 : ret_from_intr+0x0/0x15 [kernel]
理清楚了大的流程，我们再来看目前的gro小的流程。在收到一个skb的时候，我们把它和napi_struct中的gro_list的skb进行比较，看能否合并，当然合并的前提是同一个flow的，
除此之外，除了满足同一个flow，还有很多要求。
那这个gro_list最大多长呢？
/* Instead of increasing this, you should create a hash table. */ #define MAX_GRO_SKBS 8
才8个，这8个skb跟新进来的skb是flow相同的概率其实真不高，比如在tcp4_gro_receive中，我想跟踪它接着调用的 skb_gro_receive，无奈由于合并的几率太低而无法跟到，
毕竟还有一个在gro_list中停留的时间限制，为一个jiffies。后来修改了jiffies并且修改了合并的条件才能抓到。
当然，根据作者的注释，与其将这8改大，不如改成一个hash表，不同的skb先哈希到一个flow链，然后在链中比较看能否合并，这样对于gro流程需要改动为：
1.创建flow的hash表，让skb中看到flow，然后在flow的冲突链中找对应的gro_list，然后看能否合并。
2.percpu模式，不适用napi_struct来管理gro_list.
3.修改合并条件，比如对于tcp的ack来说，目前不带数据的ack无法合并，因为才54个字节，而以太网发出的时候会填充，导致不满足如下条件：
flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id & ~IP_DF));
但对于流媒体服务器来说，纯ack占入向的比例很高，需要将条件改动，由于ack还涉及到快发流程的进入和退出，所以ack合并还是有一些工作要做的。
4.修改间隔，目前限制死了是一个jiffies，比如服务器8M左右的发送码率，收到的ack间隔可以释放放大，不然合并几率也比较低，当然这个是以tcp的send_buf中的数据占用更多内存为前提的。
所以需要一个导出到/proc文件系统的间隔字段来控制。
5.对于低速发送码率的服务器来说，可以关闭gro，对于lvs服务器来说，应该关闭gro。