linux 3.10 gro的理解和改进

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 = ,
  priority = ,
  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+>,
    prev = 0xffffffff81b3f0e0 <offload_base>
  }
}
ffffffff81b43b20
struct packet_offload {
  type = ,
  priority = ,
  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+>,
    prev = 0xffffffff81b41be0 <ip_packet_offload+>
  }
}
ffffffff81b3f7a0
struct packet_offload {
  type = ,
  priority = ,
  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+>
  }
}

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

p inet_offloads
inet_offloads = $ =
 {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 ( 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。