Wie funktioniert GRO (Generic Receive Offload) auf fortgeschritteneren NICs?

Ich interessiere mich für bestimmte Antworten:

1. Bearbeitet / erstellt die Netzwerkkarte mit GRO TCP-ACK oder andere Pakete (oder ist diese Funktion für TCP-Stapel von Empfängern / Absendern transparent)?
2. Sollte es eine Zeitüberschreitung / ein Ereignis geben, bei dem die Netzwerkkarte die "geklebten Segmente" an den TCP-Stapel weiterleiten sollte? Was sind Sie?
3. Versucht die GRO-Funktion beim Einrichten der Paketweiterleitung auch, Empfänger-ACKs zu lesen (siehe unten, warum ich dies frage)?
4. Jede Quelle, die GRO und andere NIC-Offloading-Funktionen (TSO, LSO ...) besser erklärt als Wikipedia- und Linux-Manpages, wäre sehr dankbar.

Mehr Details:

Ich behebe ein Leistungsproblem mit einer IPSec-Implementierung. Das Problem ist, dass die verfügbare Bandbreite nicht gleichmäßig auf alle 4 VPN-Tunnel verteilt ist (verteilt auf ungefähr 200 Mbit / s / 200 Mbit / s / 1 Mbit / s / 1 Mbit / s; jeder VPN-Tunnel kapselt eine einzelne TCP-Verbindung). In PCAP sehe ich ab und zu, dass der Webserver für ca. 2 Sekunden im Leerlauf ist (auf ACK wartet). Der Download wird fortgesetzt, wenn der Webserver nicht bestätigte Segmente erneut überträgt.

Mein innerer Nachteil von PCAP ist, dass die NIC GRO-Funktion Pakete zusammenklebt, sie aber manchmal nicht rechtzeitig an den TCP-Stack weiterleitet, was die Probleme verursacht.

Da dieser VPN-Server keine Schnittstellen besitzt, die TCP-Verbindungen beenden, sondern nur Pakete weiterleiten. Dann habe ich versucht, GRO zu deaktivieren, und danach habe ich festgestellt, dass der Verkehr gleichmäßig über alle Tunnel verteilt ist. Auch wenn die TCP-Fensterskalierung auf dem Webserver deaktiviert ist, wird die Bandbreite auch dann verteilt, wenn GRO aktiviert ist (aus diesem Grund hatte ich Frage 3).

Ich benutze 2.6.32-27 Linux auf Ubuntu 10.04 Server (64-Bit). NIC ist Intel 82571EB. Alle Schnittstellen (HTTP-Client, VPN-Client, VPN-Server, Webserver) sind direkt in Kette mit 1-Gbit-Ethernet-Kabeln verbunden.

Ich fand diesen Artikel erstaunlich nützlich: JLS2009: Generic Receive Offload . Es gibt einen großartigen Überblick über die Funktionsweise von GRO.

1. Einige Adapter tun dies möglicherweise, aber die zugehörigen Treiber müssen dies ebenfalls berücksichtigen. Treiber können dies auch selbst in Software tun. Da dies vor dem Aufrufen des Kernel-TCP / IP-Stacks geschieht, wurden die Pakete bis zum vollständigen Aufrufen des Kernel-Space-TCP / IP-Stacks erneut sequenziert.
2. Das Timeout wird von der GRO-Spezifikation als ein TCP / IP-Tick (Inkrement des Zeitstempelfelds) definiert. Dies ist eine sehr kleine Zahl, in schnellen Netzwerken können jedoch immer noch mehrere Pakete empfangen werden.
3. GRO wird auf der Empfängerseite des Weiterleiters ins Spiel kommen, und GRO wurde in der Tat geschaffen, damit die gierigere LRO-Methode aufhört, Pakete auf Weiterleitern zu vermasseln.
4. Dieser Artikel, den ich oben verlinkt habe, hilft wirklich.

Ethtool ist möglicherweise in der Lage, GRO auf bestimmten Schnittstellen zu aktivieren / deaktivieren. Kommt auf die Version an.