理解 Linux 网络栈（2）：非虚拟化Linux 环境中的 Segmentation Offloading 技术

本系列文章总结 Linux 网络栈，包括：

（1）Linux 网络协议栈总结

（2）非虚拟化Linux环境中的网络分段卸载技术 GSO/TSO/UFO/LRO/GRO

（3）QEMU/KVM + VxLAN 环境下的 Segmentation Offloading 技术（发送端） 

（4）QEMU/KVM + VxLAN 环境下的 Segmentation Offloading 技术（接收端）

 

第一篇文章总结了Linux 网络协议栈的概括和功能。本文总结非虚拟化环境中的各种 Segmentation Offloading 技术。

1. 为什么需要 Segmentation offloading

   从第一篇文章的介绍中我们知道，Linux 内核传输层和网络层都要做大量的计算工作，具体见上图，这些计算都在服务器的主 CPU 中进行。这里有一些网络协议栈计算所需要的 CPU 资源的一些参考数据。大体上，发送或者接收 1 bit/s 的数据需要 1 赫兹的 CPU 处理能力，也就是说，5 Git/s （625 MB/s） 的网络流量大概需要 5 GHz 的 CPU 处理能力，相当于此时需要 2 个 2.5 Ghz 的多核处理器。因为以太网是单向的，发送和接收 10 Gbit/s （吞吐量就是 20 10 Gbit/s）时，大概需要 8 个 2.5 GHz 的 CPU 内核。

   这些计算大概可以分为两类：（1）数据计算，比如校验和计算和验证、分包和组包等，这个和所处理的 packets 的数量有关（2）数据传输和上下文切换带来的 overhead，这个和传输和切换的次数有关。

  为了解决问题，考虑到越来越多的物理网卡具有较强的处理能力，就出现了两个思路：

（1）如果网卡能够支持某些 Linux 内核协议栈所承担的计算任务，那么就可以将这些计算从协议栈 offload （卸载）到物理网卡。

（2）如果网卡不能支持这些计算，那么尽可能地将这些计算在 Linux 内核网络栈中延后（传输过程）和提前（接收过程）来减少 overhead。以 TCP 分组或者 IP 分片为例，延迟该过程，可以减少在网络栈中传输和处理的 packets 的数目，从而减少数据传输和上下文切换所需要的主 CPU 计算能力。

2.  Segmentation offloading 技术

2.1 TSO （TCP Segmentation Offloading）

2.1.1 TCP Segmentation （TCP 分段）

  MSS（Maxium Segment Size）： MSS 是 TCP 数据段每次能够传输的最大数据分段的长度。为了达到最佳的传输效能，TCP 协议在建立连接的时候通常要协商双方的 MSS 值，这个值 TCP 协议在实现的时候往往用 MTU 值代替（ MSS = MTU - IP 数据包包头大小20Bytes - TCP 数据段的包头大小20Bytes），所以在默认以太网 MTU 为 1500 bytes 时，MSS为 1460。

  TCP 分段：当网络应用发给 TCP 的 message 的长度超过 MSS 时，TCP 会对它按照 MSS 的大小将其分为多个小的 packet，并且在每个 packet 上添加 TCP Header 成为一个 TCP 段（segement）。

2.1.2 TSO  

  TSO 是一种利用网卡分割大数据包，减小 CPU 负荷的一种技术，也被叫做 LSO (Large segment offload) ，如果数据包的类型只能是 TCP，则被称之为 TSO，如果硬件支持 TSO 功能的话，也需要同时支持硬件的 TCP 校验计算和分散 - 聚集 (Scatter Gather) 功能。可以看到 TSO 的实现，需要一些基本条件，而这些其实是由软件和硬件结合起来完成的，对于硬件，具体说来，硬件能够对大的数据包进行分片，分片之后，还要能够对每个分片附着相关的头部。

  TSO 就是将由 TCP 协议栈所做的 TCP 分段交给具有这种能力的物理网卡去做，因此它需要如下支持：

• 物理网卡支持。
• Linux 网卡驱动支持。可以使用 ethtool -K ethX tso on 命令打开网卡和驱动对 TSO 的支持，如果返回错误则表示不支持。
• 还需要 Net:TCP checksum offloading and Net:Scatter Gather 支持。

  使用 TSO 以后，应用发出的大的数据块在不超过 64k 的情况下，将会直接经过Linux 网络栈发到网卡的驱动的 driver queue，然后在网卡中根据 skb 中的预设分组数据（主要是 MSS）对它执行 TCP 分段。下图是使用 TSO 和不使用 TSO 的情形的对比：

2.2 UFO - UDP Fragmentation Offload

   UDP 数据报，由于它不会自己进行分段，因此当长度超过了 MTU 时，会在网络层进行 IP 分片。同样，ICMP（在网络层中）同样会出现IP分片情况。

2.2.1 IP fragmentation （分片）

MTU 和 IP 分片：

• MTU：上文已经说过了，MTU 是链路层中的网络对数据帧的一个限制，依然以以太网为例，默认 MTU 为1500字节。
• IP 分片：一个 IP 数据报在以太网中传输，如果它的长度大于该 MTU 值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的 IP 数据报不一定按序到达，但 IP 首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。

IP 分片和 TCP 分段的区别：

• IP 数据报分片后，只有第一片带有UDP首部或ICMP首部，其余的分片只有IP头部，到了端点后根据IP头部中的信息再网络层进行重组。而 TCP 报文段的每个分段中都有TCP 首部，到了端点后根据 TCP 首部的信息在传输层进行重组。IP数据报分片后，只有到达目的地后才进行重组，而不是向其他网络协议，在下一站就要进行重组。
• 对 IP 分片的 TCP segment （段）来说，即使只丢失一片数据， TCP 层也要重新传整个数据报。这是因为IP层本身没有超时重传机制------由更高层（比如TCP）来负责超时和重传。当来自TCP报文段的某一段（在IP数据报的某一片中）丢失后，TCP在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报（可能有多个IP分片），没有办法只重传数据报中的一个数据分片。这就是为什么对 TCP 来说要尽量避免 IP 分片的原因。

IP 分片和 TCP 分段的关系：

• 在非虚拟化环境中，MSS 肯定是要比 MTU 小的，因此，每个 TCP 分组不再需要 IP 分片就可以直接交给网卡去传输。
• 在虚拟户环境中，如果配置不当，虚机网络应用的 TCP 连接的 MSS 比宿主机物理网卡的 MTU 大的情况下，宿主机上还是会执行 IP 分片的。

2.2.2 UFO

  UDP 协议层本身不对大的数据报进行分片，而是交给 IP 层去做。因此，UFO 就是将 IP 分片 offload 到网卡（NIC）中进行。其原理同 TSO。

  "IPv4/IPv6: UFO (UDP Fragmentation Offload) Scatter-gather approach: UFO is a feature wherein the Linux kernel network stack will offload the IP fragmentation functionality of large UDP datagram to hardware. This will reduce the overhead of stack in fragmenting the large UDP datagram to MTU sized packets"

2.3 GSO - Generic Segemetation Offload

   TSO 是使得网络协议栈能够将大块 buffer 推送至网卡，然后网卡执行分片工作，这样减轻了 CPU 的负荷，但 TSO 需要硬件来实现分片功能；而性能上的提高，主要是因为延缓分片而减轻了 CPU 的负载，因此，可以考虑将 TSO 技术一般化，因为其本质实际是延缓分片，这种技术，在 Linux 中被叫做 GSO(Generic Segmentation Offload)。它比 TSO 更通用，原因在于它不需要硬件的支持分片就可使用，对于支持 TSO 功能的硬件，则先经过 GSO 功能，然后使用网卡的硬件分片能力执行分片；而对于不支持 TSO 功能的网卡，将分片的执行，放在了将数据推送的网卡的前一刻，也就是在调用驱动的 xmit 函数前。  

   根据网卡是否支持 TSO/UFO，GSO 有以下几种处理方式：

• （1）对 TCP，如果网卡支持 TSO， 则 GSO 使用 TSO。如果不支持，则到 （3）。
• （2）对 UDP，如果网卡支持 UFO，则 GSO 使用 UFO。如果不支持，则到 （3）。
• （3）在不支持 TSO 或者 UFO 的情况下，则延迟 TCP 分段或者 IP 分组至进入网卡驱动层之前，分组后再由驱动发给物理网卡。

  可见：

• 其原理是在发送端尽可能延缓分组至最后一个阶段，要么是网卡中，要么是进入网卡驱动之前。
• GSO 虽然没有 UFO 和 TSO 带来那么高的性能提升，但是还是能带来一些提升。
• 可以用于 TCP 和 UDP。
• 不需要修改网卡和网卡驱动。

2.3.1 在物理网卡不支持 UFO 时，使用和不使用 GSO 的情形

2.3.2 在网卡不支持 TSO 时，使用和不使用 GSO 的情形

2.4 LRO （Large Receive Offload）   

    Linux 在 2.6.24 中加入了支持 IPv4 TCP 协议的 LRO (Large Receive Offload) ，它通过将多个 TCP 数据聚合在一个 skb 结构，在稍后的某个时刻作为一个大数据包交付给上层的网络协议栈，以减少上层协议栈处理 skb 的开销，提高系统接收 TCP 数据包的能力。当然，这一切都需要网卡驱动程序支持。理解 LRO 的工作原理，需要理解 sk_buff 结构体对于负载的存储方式，在内核中，sk_buff 可以有三种方式保存真实的负载：

1. 数据被保存在 skb->data 指向的由 kmalloc 申请的内存缓冲区中，这个数据区通常被称为线性数据区，数据区长度由函数 skb_headlen 给出
2. 数据被保存在紧随 skb 线性数据区尾部的共享结构体 skb_shared_info 中的成员 frags 所表示的内存页面中，skb_frag_t 的数目由 nr_frags 给出，skb_frags_t 中有数据在内存页面中的偏移量和数据区的大小
3. 数据被保存于 skb_shared_info 中的成员 frag_list 所表示的 skb 分片队列中

    合并了多个 skb 的超级 skb，能够一次性通过网络协议栈，而不是多次，这对 CPU 负荷的减轻是显然的。

 

2.5 GRO （Generic Receive Offloading）

  前面的 LRO 的核心在于：在接收路径上，将多个数据包聚合成一个大的数据包，然后传递给网络协议栈处理，但 LRO 的实现中存在一些瑕疵：

• 数据包合并可能会破坏一些状态
• 数据包合并条件过于宽泛，导致某些情况下本来需要区分的数据包也被合并了，这对于路由器是不可接收的
• 在虚拟化条件下，需要使用桥接功能，但 LRO 使得桥接功能无法使用
• 实现中，只支持 IPv4 的 TCP 协议

  而解决这些问题的办法就是新提出的 GRO。首先，GRO 的合并条件更加的严格和灵活，并且在设计时，就考虑支持所有的传输协议，因此，后续的驱动，都应该使用 GRO 的接口，而不是 LRO，内核可能在所有先有驱动迁移到 GRO 接口之后将 LRO 从内核中移除。GRO 和 LRO 的最大区别在于，GRO 保留了每个接收到的数据包的熵信息，这对于像路由器这样的应用至关重要，并且实现了对各种协议的支持。以 IPv4 的 TCP 为例，匹配的条件有：

• 源 / 目的地址匹配
• TOS/ 协议字段匹配
• 源 / 目的端口匹配

2.5.1 在不支持 LRO 的情况下，对 TCP 使用和不使用 GRO 的情形

2.6 TCP/UDP Segementation Offload 小结

2.6.1 小结

Offload	传输段还是接收端	针对的协议	Offloading 的位置	ethtool 命令输出中的项目	ethtool 命令中的 option	网卡/Linux 内核支持情况
TSO	传输段	TCP	NIC	tcp-segmentation-offload	tso	Linux 内核从 2.5.33 引入 （2002） 网卡普遍支持
UFO	传输段	UDP	NIC	udp-fragmentation-offload	ufo	linux 2.6.15 引入 （2006） 网卡普遍不支持
GSO	传输段	TCP/UDP	NIC 或者 离开 IP 协议栈进入网卡驱动之前	generic-segmentation-offload	gso	GSO/TCP: Linux 2.6.18 中引入（2006） GSP/UDP: linux 3.16 (2014)
LRO	接收段	TCP	NIC	large-receive-offload	lro	Linux 内核 2.6.24 引入（2008） 网卡普遍支持
GRO	接收段	TCP	NIC 或者离开网卡驱动进入 IP 协议栈之前	generic-receive-offload	gro	Linux 内核 2.6.18 引入(2006) 网卡普遍支持

 

2.6.2  Offloading 带来的潜在问题

  分段offloading 可能会带来潜在的问题，比如网络传输的延迟 latency，因为 packets 的大小的增加，大大增加了 driver queue 的容量（capacity）。比如说，系统一方面在使用大的 packet size 传输大量的数据，同时在运行许多的交换式应用（interactive application）。因为交互式应用会定时发送许多小的packet，这时候可能会应为这些小的 packets 被淹没在大的 packets 之中，需要等待较长的时间才能被处理，这可能会带来不可接受的延迟。

  在网络上也能看到一些建议，在使用这些 offloading 技术时如果发现莫名的网络问题，建议先将这些技术关闭后再看看情况有没有改变。

 

参考链接：

• http://www.slideshare.net/eurobsdcon/20140928-gso-eurobsdcon2014
• Linux 下网络性能优化方法简析