Яким чином GRO (загальне отримання розвантаження) працює на більш просунутих NIC?

Мене цікавлять конкретні відповіді:

1. Чи редактор NIC з GRO редагує / створює TCP ACK або будь-які інші пакети (чи ця функція прозора для TCP стеків приймача / відправника)?
2. Повинно бути час / подія, коли NIC повинен передати "склеєні сегменти" до стеку TCP? Хто вони?
3. У налаштуваннях переадресації пакетів - чи функція GRO також намагається прочитати ACK приймачів (див. Нижче, чому я це запитую)?
4. Будь-яке джерело, яке пояснює GRO, а також інші функції розвантаження NIC (TSO, LSO ...), які краще, ніж вікіпедії та користувацькі сторінки Linux, було б дуже вдячне.

Детальніше:

Я вирішую проблему продуктивності однієї програми IPSec. Проблема полягає в тому, що наявна пропускна здатність не рівномірно розподіляється по всіх 4 тунелях VPN (розподіляється приблизно як 200MBps / 200MBps / 1MBps / 1MBps; Кожен тунель 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, веб-сервер) з'єднані безпосередньо ланцюжком з 1 Гбіт Ethernet-кабелями.

Я вважаю цю статтю надзвичайно корисною: JLS2009: Загальне отримання розвантаження . Це дає чудовий огляд того, як працює GRO.

1. Деякі адаптери можуть це зробити, але про це повинні знати і пов'язані драйвери. Також самі драйвери можуть це робити в програмному забезпеченні. Як це відбувається перед входом у стек TCP / IP ядра, до моменту повноти входу ядра TCP / IP в ядро ​​пакети будуть повторно виконані.
2. Час очікування визначається специфікацією GRO як один "галочка" TCP / IP (приріст поля "Часова позначка"), що є дуже невеликою кількістю, але у швидких мережах все-таки може бути отримано кілька пакетів.
3. GRO ввійде в гру на приймальній стороні експедитора, і насправді GRO був створений таким чином, щоб більш жадібний метод LRO перестав перекручувати пакети на експедиторах.
4. Ця стаття, про яку я посилався вище, справді допомагає.

Ethtool може мати змогу вмикати / вимикати GRO на певних інтерфейсах. Залежить від версії.