Как GRO (универсальная разгрузка приема) работает на более продвинутых сетевых картах?

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

1. NIC с GRO редактирует / создает TCP ACK или любые другие пакеты (или эта функция прозрачна для стеков TCP получателя / отправителя)?
2. Должен быть тайм-аут / событие, когда сетевая карта должна передать «склеенные сегменты» в стек TCP? Кто они такие?
3. При настройке пересылки пакетов - функция GRO также пытается прочитать ACK получателя (см. Ниже, почему я спрашиваю это)?
4. Любой источник, который объясняет GRO, а также другие функции разгрузки NIC (TSO, LSO ...) лучше, чем справочные страницы Википедии и 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-разрядная версия). NIC - это Intel 82571EB. Все интерфейсы (HTTP-клиент, VPN-клиент, VPN-сервер, веб-сервер) соединены напрямую в цепочку с кабелями Ethernet 1 Гбит.

Я нашел эту статью удивительно полезной: JLS2009: Общий прием разгрузки . Это дает большой обзор того, как работает GRO.

1. Некоторые адаптеры могут это делать, но соответствующие драйверы также должны об этом знать. Кроме того, сами драйверы могут сделать это в программном обеспечении. Поскольку это происходит до входа в стек TCP / IP ядра, к моменту полного ввода стека TCP / IP в пространстве ядра пакеты были повторно упорядочены.
2. Время ожидания определяется спецификацией GRO как один тик TCP / IP (приращение поля метки времени), который является очень небольшим числом, но в быстрых сетях все еще могут быть получены несколько пакетов.
3. GRO вступит в игру на принимающей стороне сервера пересылки, и фактически GRO был создан для того, чтобы более жадный метод LRO перестал портить пакеты на серверах пересылки.
4. Та статья, на которую я ссылаюсь выше, действительно помогает.

Ethtool может включать / отключать GRO на определенных интерфейсах. Зависит от версии.