📚 课程目录第4章 GRO核心原理

4、GRO核心原理：Generic Receive Offload，将多个小包合并为大包，减少协议栈处理次数。

Generic Receive Offload（GRO）是 Linux 内核接收路径上的一项关键卸载技术。其核心思想非常直观：将多个连续、同属一个数据流的小包（packets）在网卡驱动层或软中断上下文中合并成一个更大的超级包（super-packet），然后一次性提交给上层协议栈处理。通过减少协议栈遍历次数和元数据开销，GRO 能够显著提升高吞吐场景下的网络性能。

4.1 为什么需要GRO？小包处理的开销困境

在高速网络（如 10GbE、40GbE）环境下，CPU 处理每个数据包都需要经历以下固定开销：

中断与软中断：NAPI 轮询调度、sk_buff 分配。
协议栈遍历：L2（MAC）→ L3（IP）→ L4（TCP/UDP）逐层解析。
元数据操作：校验和验证、时间戳、流哈希计算。
内存操作：sk_buff 与数据缓冲区管理、Cache 行失效。

当数据包尺寸较小（例如 64 字节 TCP ACK 或 128 字节 VoIP 报文）时，每比特有效载荷所分摊的 CPU 开销急剧上升。GRO 通过合并操作，将多个小包的处理成本摊薄到一个大包上，从而突破 CPU 瓶颈。

    关键指标：在 10GbE 线速下，64 字节小包每秒可达 14.88 Mpps（百万包/秒）。未经 GRO 优化时，单核 CPU 通常只能处理 1–2 Mpps；启用 GRO 后，合并后的大包可将 PPS 需求降低 5–10 倍，使单核吞吐提升至 5–10 Gbps。

4.2 GRO合并的三大核心条件

GRO 并非盲目合并所有到达的包。它必须严格遵循以下条件，以保证合并后的超级包在语义上与原始小包序列完全等价：

条件类别	具体检查项	说明
流标识一致	源/目的 MAC、IP、端口、协议号	必须属于同一个 5 元组（或 L2/L3/L4 流）
IP 层连续	IP ID 连续、DF 位一致、TTL 一致	确保无乱序、无分片交错
TCP 层连续	序列号连续、ACK 号一致、标志位一致	仅合并纯数据段，不合并 SYN/FIN/RST 控制包
时间窗口	GRO flush 定时器 / 包计数阈值	防止合并延迟过大导致 TCP 重传

实践要点：GRO 对 UDP 流的合并支持较弱（通常仅合并相同 L4 校验和且无分片的连续包）。对于 UDP 组播或视频流场景，建议结合 UDP GRO 补丁或使用 LRO 硬件卸载。

4.3 GRO合并流程：从驱动到协议栈

GRO 的合并操作发生在 NAPI 轮询上下文中，位于网卡驱动 ndo_poll 回调函数与 netif_receive_skb 之间。其核心流程如下：

驱动接收：网卡 DMA 将数据写入 Ring Buffer，驱动构造 sk_buff 并调用 napi_gro_receive()。
流查找：GRO 模块根据 5 元组哈希查找当前流对应的 gro_list 中的待合并包。
条件检查：对新包与 gro_list 中的旧包执行上述三大条件检查。
合并或追加：若条件满足，调用 skb_gro_receive() 将新包数据追加到旧包的 frag_list 中；否则将新包作为新的流头部加入 gro_list。
Flush 提交：当达到 flush 条件（定时器到期、包计数超限、TCP 确认号变化）时，将合并后的超级包通过 napi_gro_complete() 提交给 __netif_receive_skb_core() 进入协议栈。

4.4 GRO数据结构：gro_list 与 sk_buff 的合并

GRO 的核心数据结构是每个 NAPI 实例维护的 gro_list（一个链表头）。每个流在 gro_list 中对应一个 头部 sk_buff，后续同流的小包通过 sk_buff->frag_list 指针链接到头部包上。

合并后的超级包在内存布局上表现为：

头部 sk_buff：包含完整的 L2–L4 头部，以及合并后的总长度、校验和等信息。
frag_list 链：每个被合并的小包作为一个独立的 sk_buff 结构，通过 next 指针串联，其数据指针指向原始 DMA 缓冲区。
零拷贝特性：合并过程不涉及数据拷贝，仅通过指针操作将多个 sk_buff 组织成链表，因此 CPU 开销极低。

    性能数据：在典型 TCP 流（MTU 1500）场景下，GRO 可将协议栈处理次数减少约 60%–80%。例如，接收 100 个 1460 字节的 TCP 段，若不启用 GRO，协议栈需处理 100 次；启用 GRO 后，若合并为 10 个超级包（每个约 14.6 KB），处理次数降至 10 次。

4.5 GRO与硬件LRO的对比

GRO 是纯软件实现，而 LRO（Large Receive Offload）是网卡硬件卸载。两者目标相同，但存在关键差异：

特性	GRO（软件）	LRO（硬件）
实现位置	内核 NAPI 层（软件）	网卡固件 / ASIC
合并粒度	严格按 TCP 序列号连续合并	可能放宽条件，存在乱序风险
协议支持	TCP、UDP（有限）、IPIP、GRE	通常仅 TCP/IPv4
转发场景	完全兼容，不破坏中间设备逻辑	可能破坏 TTL、IP ID 语义，不推荐用于路由器
CPU 开销	较低（仅指针操作）	极低（硬件完成）

重要提醒：在 Linux 作为路由器或防火墙的场景下，必须禁用硬件 LRO（使用 ethtool -K ethX lro off），因为 LRO 可能破坏 IP 选项、TTL 等字段，导致路由决策错误。GRO 作为软件实现，严格遵循协议语义，是转发场景的安全选择。

4.6 GRO的配置与调试

GRO 默认在主流 Linux 发行版中启用。可通过以下命令查看和修改：

# 查看 GRO 状态（ethtool）
ethtool -k eth0 | grep gro
# 输出示例：generic-receive-offload: on

# 临时关闭 GRO（用于对比测试）
ethtool -K eth0 gro off

# 重新开启 GRO
ethtool -K eth0 gro on

# 查看 GRO 统计信息（通过 /proc）
cat /proc/net/softnet_stat
# 第 3 列（time_squeeze）反映 GRO flush 被定时器强制提交的次数

在调优场景下，可通过 sysfs 调整 GRO 的 flush 参数：

# 查看当前 NAPI 实例的 GRO flush 定时器频率（单位：ns）
cat /sys/class/net/eth0/gro_flush_timeout
# 默认值通常为 0（由内核自动管理），可设置为 10000（10us）以降低延迟

4.7 小结：GRO的核心价值

GRO 通过软件层面的智能合并，在不依赖特定硬件的前提下，将小包处理的 CPU 开销降低一个数量级。其核心优势在于：

零拷贝合并：仅通过指针操作，无数据搬移。
严格语义等价：不破坏 TCP/IP 协议状态机。
透明兼容：对应用层和中间设备完全透明。
动态自适应：根据流速率和 CPU 负载自动调整合并策略。