我对以下具体答案感兴趣：
- 具有 GRO 的 NIC 是否会编辑/创建 TCP ACK 或任何其他数据包（或者此功能对接收器/发送器 TCP 堆栈是否透明）？
- 当 NIC 将“粘合段”传递到 TCP 堆栈时，应该发生超时/事件吗？它们是什么？
- 在数据包转发设置中 - GRO 功能是否也尝试读取接收器 ACK（请参阅下文我为什么要问这个问题）？
- 任何能够比维基百科和 Linux 手册页更好地解释 GRO 以及其他 NIC 卸载功能（TSO、LSO...）的资料来源都将不胜感激。
更多细节：
我正在排除一个 IPSec 实施的性能问题。问题是可用带宽并非均匀分布在所有 4 个 VPN 隧道上（大约分布为 200MBps/200MBps/1MBps/1MBps；每个 VPN 隧道封装单个 TCP 连接）。在 PCAP 中，我偶尔会看到 Web 服务器空闲约 2 秒（等待 ACK）。当 Web 服务器重新传输未确认的段时，下载将恢复。
我从 PCAP 中得到的内心感受是，NIC GRO 功能将数据包粘合在一起，但有时不能及时将它们传递给 TCP 堆栈，从而导致问题。
由于此 VPN 服务器没有终止 TCP 连接的接口，而只是转发数据包。然后我尝试禁用 GRO，之后我观察到流量均匀分布在所有隧道上。此外，当在 Web 服务器上禁用 TCP 窗口缩放时，即使启用了 GRO，带宽也会均匀分布（这就是我提出问题 #3 的原因）。
我在 Ubuntu 10.04 服务器 (64 位) 上使用 2.6.32-27 Linux。NIC 是 Intel 82571EB。所有接口 (HTTP 客户端、VPN 客户端、VPN 服务器、Web 服务器) 都通过 1Gbit 以太网电缆直接连接。
答案1
我发现这篇文章非常有用：JLS2009：通用接收卸载。它很好地概述了 GRO 的工作原理。
- 某些适配器可能会这样做，但相关驱动程序也必须意识到这一点。此外，驱动程序本身也可以在软件中执行此操作。由于这发生在进入内核 TCP/IP 堆栈之前，因此在完全进入内核空间 TCP/IP 堆栈时，数据包已重新排序。
- GRO 规范将超时定义为一个 TCP/IP“刻度”（时间戳字段的增量），这是一个非常小的数字，但在快速网络上仍可能会收到多个数据包。
- GRO 将在转发器的接收端发挥作用，事实上，GRO 的创建是为了让更贪婪的 LRO 方法停止破坏转发器上的数据包。
- 我上面链接的那篇文章确实有帮助。
Ethtool可能能够在特定接口上启用/禁用 GRO。取决于版本。