Comment GRO (déchargement de réception générique) fonctionne sur des cartes réseau plus avancées?


14

Je suis intéressé par des réponses particulières:

  1. La carte réseau avec GRO édite / crée TCP ACK ou tout autre paquet (ou cette fonctionnalité est-elle transparente pour les piles TCP du récepteur / expéditeur)?
  2. Il devrait y avoir un délai d'expiration / événement lorsque la carte réseau devrait transmettre les «segments collés» à la pile TCP? Que sont-ils?
  3. Dans la configuration de transfert de paquets - la fonction GRO essaie-t-elle également de lire les accusés de réception du récepteur (voir ci-dessous pourquoi je pose cette question)?
  4. Toute source expliquant GRO et également d'autres fonctionnalités de déchargement de carte réseau (TSO, LSO ...) mieux que les pages de manuel wikipedia et linux serait vraiment appréciée.

Plus de détails:

Je dépanne un problème de performances avec une implémentation IPSec. Le problème est que la bande passante disponible n'est pas répartie uniformément sur les 4 tunnels VPN (répartis approximativement sous la forme de 200 Mbps / 200 Mbps / 1 Mbps / 1 Mbps; chaque tunnel VPN encapsule une seule connexion TCP). Dans PCAP de temps en temps, je vois que le serveur Web reste inactif pendant environ 2 secondes (en attendant ACK). Le téléchargement reprend lorsque le serveur Web retransmet des segments non reconnus.

Mon impression intérieure de PCAP est que la fonctionnalité NIC GRO colle les paquets ensemble mais parfois ne les transmet pas à la pile TCP en temps opportun et cela cause les problèmes.

Comme ce serveur VPN n'a pas d'interfaces qui mettent fin aux connexions TCP, mais transfère uniquement les paquets. Ensuite, j'ai essayé de désactiver GRO et après cela, j'ai observé que le trafic était réparti uniformément sur tous les tunnels. De plus, lorsque la mise à l'échelle de la fenêtre TCP est désactivée sur le serveur Web, la bande passante est également distribuée même avec GRO activé (c'est pourquoi j'avais la question n ° 3).

J'utilise 2.6.32-27 linux sur le serveur Ubuntu 10.04 (64 bits). La carte réseau est Intel 82571EB. Toutes les interfaces (client HTTP, client VPN, serveur VPN, serveur Web) sont connectées directement en chaîne avec des câbles Ethernet 1 Gbit.

Réponses:


15

J'ai trouvé cet article incroyablement utile: JLS2009: déchargement de réception générique . Il donne un excellent aperçu du fonctionnement de GRO.

  1. Certains adaptateurs peuvent le faire, mais les pilotes associés doivent également en être conscients. Les pilotes eux-mêmes peuvent également le faire dans le logiciel. Comme cela se produit avant d'entrer dans la pile TCP / IP du noyau, au moment où la pile TCP / IP de l'espace noyau est entièrement entrée, les paquets ont été reséquencés.
  2. Le délai d'attente est défini par la spécification GRO comme un «tick» TCP / IP (incrément du champ Horodatage), qui est un très petit nombre mais sur les réseaux rapides, plusieurs paquets peuvent toujours être reçus.
  3. GRO entrera en jeu du côté de la réception du transitaire, et en fait, GRO a été créé pour que la méthode LRO plus gourmande arrête de visser les paquets sur les transitaires.
  4. Cet article que j'ai lié ci-dessus aide vraiment.

Ethtool peut être en mesure d'activer / désactiver GRO sur des interfaces spécifiques. Dépend de la version.


1
J'ai mis à jour ma question. Il semble que vous ayez répondu n ° 1 dans le contexte de toutes les fonctionnalités de déchargement (IMHO GRO seul ne génère pas d'ACK - il "colle" uniquement tous les paquets pour un tick TCP / IP, puis les gère sur OS). Je vous remercie!
user389238
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.