GRO（通用接收卸载）如何在更高级的NIC上工作？

我对特定答案感兴趣：

1. 具有GRO的NIC是否会编辑/创建TCP ACK或任何其他数据包（或者此功能对接收者/发送者TCP堆栈透明）？
2. NIC应该将“粘合段”传递到TCP堆栈时应该有一个超时/事件？这些是什么？
3. 在数据包转发设置中-GRO功能是否还会尝试读取接收器的ACK（请参阅下文，为什么我要这样做）？
4. 任何比Wikipedia和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以太网电缆成链连接。

我发现本文非常有用：JLS2009：通用接收卸载。它概述了GRO的工作原理。

1. 某些适配器可能会这样做，但是相关的驱动程序也必须意识到这一点。而且，驱动程序本身可以在软件中执行此操作。由于这是在进入内核TCP / IP堆栈之前发生的，到内核空间TCP / IP堆栈完全进入时，已对包进行了重新排序。
2. GRO规范将超时定义为一个TCP / IP'tick'（时间戳字段的增量），该数目非常小，但在快速网络上仍可能会收到多个数据包。
3. GRO将在转发器的接收端发挥作用，并且实际上创建了GRO，因此更加贪婪的LRO方法将停止在转发器上破坏数据包。
4. 我上面链接的那篇文章确实有帮助。

Ethtool 可能能够在特定接口上启用/禁用GRO。取决于版本。