Как GRO (generic receive offload) работает на более продвинутых сетевых адаптерах?

Меня интересуют конкретные ответы:

1. Редактирует ли сетевая карта с GRO для редактирования / создания TCP ACK или любых других пакетов (или эта функция прозрачна для стеков TCP получателя / отправителя)?
2. Должен быть тайм-аут / событие, когда сетевой адаптер должен передать «склеенные сегменты» в стек TCP? Кто они такие?
3. При настройке пересылки пакетов - функция GRO также пытается читать ACK получателя (см. Ниже, почему я спрашиваю об этом)?
4. Любой источник, который объясняет GRO, а также другие функции разгрузки сетевых адаптеров (TSO, LSO ...) лучше, чем справочные страницы wikipedia и linux, будет действительно оценен.

Подробнее:

Я устраняю проблемы с производительностью с помощью одной реализации IPSec. Проблема в том, что доступная полоса пропускания не распределяется равномерно по всем 4 туннелям VPN (примерно как 200 Мбит / с / 200 Мбит / с / 1 Мбит / с / 1 Мбит / с; каждый VPN-туннель инкапсулирует одно TCP-соединение). В PCAP время от времени я вижу, что веб-сервер простаивает около 2 секунд (ожидая ACK). Загрузка возобновляется, когда веб-сервер повторно передает неподтвержденные сегменты.

Мое внутреннее ощущение от PCAP состоит в том, что функция NIC GRO склеивает пакеты вместе, но иногда не передает их в стек TCP вовремя, и это вызывает проблемы.

Поскольку этот VPN-сервер не имеет интерфейсов, которые завершают TCP-соединения, а только пересылают пакеты. Затем я попытался отключить GRO и после этого заметил, что трафик равномерно распределяется по всем туннелям. Кроме того, когда масштабирование окна TCP отключено на веб-сервере, пропускная способность также распределяется даже при включенном GRO (поэтому у меня возник вопрос № 3).

Я использую 2.6.32-27 linux на сервере Ubuntu 10.04 (64-бит). Сетевая карта - Intel 82571EB. Все интерфейсы (HTTP-клиент, VPN-клиент, VPN-сервер, веб-сервер) связаны напрямую в цепочку с помощью кабелей Ethernet 1 Гбит.