Auteur Sujet: TCP offload engine - Segmentation réalisée par la carte réseau  (Lu 46600 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
TCP offload engine - Segmentation et Checksum réalisée par la carte réseau pour décharger le CPU

En réalisant une capture Wireshark, ce que nous voyons n'est pas toujours ce que est attendu. C'est le cas quand les opérations de TCP/IP sont déchargées par le système d'exploitation sur la carte réseau (NIC). Les opérations courantes pour le déchargement sont la segmentation et les calculs de checksum. Au lieu que ce soit le système d'exploitation qui réalise le calcul de la ségmentaiton en paquet de 1500 octets en utilisant le processeur central, il permet d'utiliser le propre processeur de la carte réseau pour effectuer la segmentation. Cela permet d'économiser sur le processeur et de diminuer les communications sur le bus PCI de / à partir de la carte réseau. Cependant, ce déchargement ne change pas ce qui est envoyé sur le réseau. En d'autres termes, le déchargement à la carte réseau peut produire des gains de performance à l'intérieur de votre ordinateur, mais pas à travers le réseau. C'est même le contraire, certains réseaux (Orange FTTH, câble avec TCP ACK Suppression,...) peuvent souffrir du déchargement des opérations a la carte réseau.

Comment TCP offload engine affecte ce que Wireshark capture ?

Quand les calculs de checksum sont réalisés par la carte réseau au lieu du CPU, Wieshark capture des trames avec un checksum incorrect en émission, rempli de 00000 (en réception il est bon, bcar la carte réseau de l'èmetteur a fait le calcul et remplacé les 000000 par le vrai checksum).

Plus complexe, la segmentation réalisée par la carte réseau : La figure ci-dessous illustre le flux normal des données grâce à une pile TCP/IP sans déchargement. Supposons les données d'application est 7300 octets. TCP rompt ces 7300 octets en 5 segments qui formeront 5 paquets. Pourquoi 5 ? Le Maximum Transmission Unit (MTU) d'Ethernet est de 1500 octets (il est inférieur avec certains FAI qui utilisent le PPPoE ou le L2TP). Si nous soustrayons l'en-tête IP de 20 octets et 20 octets en-tête TCP il reste 1460 octets des données dans un segment TCP (1460 est la taille maximum des segments TCP (MSS)). 7300 Bytes peuvent être facilement segmentés en cinq segments TCP maximales moyennes.



La couche IP ajoute ensuite un en-tête aux segments TCP. Les datagrammes IP qui en résultent sont envoyés un par un à la "couche Ethernet". Notez que le protocole TCP / IP font partie du système d'exploitation, tandis que la plupart des fonctionnalités d'Ethernet sont mis en œuvre sur la carte réseau. Cependant les pilotes réseau (permet de les considérer comme partie du système d'exploitation) peuvent également effectuer certaines fonctionnalités Ethernet. Le pilote réseau crée / reçoit des trames Ethernet. Ainsi dans l'exemple ci-dessus, en supposant que la segmentation de déchargement n'est pas utilisé, les 7300 octets de données d'application est segmenté en 5 paquets TCP / IP contenant 1460 octets de données chacune. Le pilote réseau encapsule chaque datagramme IP dans une trame Ethernet et envoyer les images à la carte réseau. Ce sont ces trames Ethernet que Wireshark (et d'autres logiciels de capture de paquets, comme tcpdump ) des captures. Le NIC envoie ensuite les cadres, un par un, sur le réseau.

Lorsque la segmentation est déchargée sur la carte réseau, nous obtenons la figure ci-dessous. Le système d'exploitation ne segmente pas les données d'application, mais crée plutôt un grand paquet TCP / IP et l'envoie au conducteur. Les en-têtes TCP et IP sont en fait des en-têtes de modèle . Le conducteur crée une seule trame Ethernet (qui est capturé par Wireshark) et l'envoie à la carte réseau. Quand la carte réseau effectue la segmentation, elle utilise les en-têtes de modèles pour créer des trames Ethernet avec 5 vraies en-têtes TCP/IP Ethernet. Les 5 images sont ensuite envoyées sur le réseau.



Le résultat: bien que les 5 mêmes trames Ethernet sont envoyées sur le réseau, Wireshark capture des données différentes en fonction de l'utilisation de "TCP offload engine". Lorsque le déchargement de segmentation par la carte réseau n'est pas utilisée, les 5 trames Ethernet sont capturés. Lorsque le déchargement est utilisé, Wireshark ne capture qu'un unique paquet TCP/IP de grande taille (contenant 7300 octets de données). L'exemple est donné avec 7,3 Ko de données, mais il est possible d'aller jusqu’à 64 Ko de données.

Un exemple en IPv4 (depuis https://lafibre.info/testdebit/testdebit.html) : dés la réponse au GET, le serveur envoi deux paquets d'un coup. On passe ensuite à 3 paquets (4414 octets) avant de monter a plus...


Un peu plus tard tous les paquets sont des bloc de 45 paquets (45 * 1428 = 64260 de data + 90 octets d'en-tête = 64350 octets)
On reçois donc beaucoup acquittements pour un big paquet envoyé (un paquet sur deux est normalement acuité) !


Cela marche également en IPv6 (toujours depuis https://lafibre.info/testdebit/testdebit.html) :


Un peu plus tard tous les paquets sont des bloc de 45 paquets (45 * 1448 = 65160 de data + 70 octets d'en-tête = 65230 octets)


Documentation sur le TCP offload engine :
(cliquez sur la miniature ci-dessous - le document est au format PDF)

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #1 le: 21 juin 2012 à 22:47:01 »
Comment savoir ce que propose votre carte réseau pour décharger le CPU ?

Sous linux, il faut installer le paquet "ethtool" (sudo apt install ethtool)
Et taper en ligne de commande :
$ sudo ethtool -k eth0

-k donne les paramètres Offload pour la carte réseau (eth0 pour la première carte réseau Ethernet).
-K change les paramètres Offload demandés pour la carte réseau.

Lexique :
- TCP Offload Engine = Moteur de déchargement TCP
- rx-checksumming (rx on|off) = Déchargement de la somme de contrôle en réception
- tx-checksumming (tx on|off) = Déchargement de la somme de contrôle en émission
- scatter-gather (sg on|off) = comme DMA : Les données circulant de ou vers la carte réseau sont transférées directement vers la mémoire principale de la machine, sans intervention du microprocesseur (si ce n'est pour lancer et conclure le transfert).
- tcp-segmentation-offload (tso on|off) = Déchargement de la segmentation d'un gros paquet TCP en plusieurs petits (en émission)
- udp-fragmentation-offload (ufo on|off) = Déchargement de la fragmentation d'un gros paquet UDP en plusieurs petits (en émission)
- generic-segmentation-offload (gso on|off) = Déchargement de la segmentation d'un gros paquet TCP en plusieurs petits (en émission)
- generic-receive-offload (gro on|off) = Déchargement en fusionnant des petits paquets TCP reçus du réseau en un gros paquet pour le système (c'est donc en réception)
- large-receive-offload (lro on|off) = Déchargement important à la réception
- rx-vlan-offload (rxvlan on|off) = Déchargement de la gestion des Vlan en réception
- tx-vlan-offload (txvlan on|off) = Déchargement de la gestion des Vlan en émission
- ntuple-filters (ntuple on|off) = ??
- receive-hashing (rxhash on|off) = receive hashing offload

Combinaisons on / off :
- Il est nécessaire d'activer tx-checksumming (tx on) pour activer scatter-gather
- Il est nécessaire d'activer tx-checksumming (tx on) et scatter-gather (sg on) pour activer tcp-segmentation-offload ou generic-segmentation-offload

Désactiver ce qui fait chuter le débit avec "TCP ACK Supression" activé sur une box : sudo ethtool -K eth0 tso off gso off
tcp-segmentation-offload et generic-segmentation-offload chacun séparèment ou activé tous les deux font chuter fortement le débit avec TCP ACK Supression.
Au contraire scatter-gather permet de gagner du débit avec "TCP ACK Supression" activé.
- TOE entièrement activé (défaut) : 3 min 13 secondes pour télécharger le fichier test
- TOE entièrement dés-activé : 56 secondes pour télécharger le fichier test
- Tout désactivé sauf tx-checksumming et scatter-gather : 33 secondes pour télécharger le fichier test
- Seul tcp-segmentation-offload et generic-segmentation-offload désactivé : 33 secondes pour télécharger le fichier test

A noter qu'avec "TCP ACK Supression" désactivé ou qui n'existe pas (cas des majorités des box) on a :
- TOE entièrement activé (défaut) : 21 secondes pour télécharger le fichier test
- TOE entièrement dés-activé : 49 secondes pour télécharger le fichier test
- Tout désactivé sauf tx-checksumming et scatter-gather : 32 secondes pour télécharger le fichier test
- Seul tcp-segmentation-offload et generic-segmentation-offload désactivé : 32 secondes pour télécharger le fichier test


Désactiver entièrement TCP offload engine :
sudo ethtool -K eth0 rx off tx off sg off tso off ufo off gso off gro off lro off rxvlan off txvlan off ntuple off rxhash off
Si vous avez le message "Cannot set device udp large send offload settings: Operation not supported", utilisez la commande suivante :
sudo ethtool -K eth0 rx off tx off sg off tso off gso off gro off lro off rxvlan off txvlan off ntuple off rxhash off

Activer entièrement TCP offload engine :
sudo ethtool -K eth0 rx on tx on sg on tso on ufo on gso on gro on lro on rxvlan on txvlan on ntuple on rxhash on
En cas d'erreur sur l'UDP :
sudo ethtool -K eth0 rx on tx on sg on tso on gso on gro on lro on rxvlan on txvlan on ntuple on rxhash on
En cas d'erreur sur UDP, large-receive-offload, ntuple-filters :
sudo ethtool -K eth0 rx on tx on sg on tso on gso on gro on rxvlan on txvlan on rxhash on

Voici les résultats compilés en fonction des cartes réseaux des machines que j'ai sous la main :

Cartes 1 Gb/s :
Carte 1 (intégrée sur serveur Intel de 2011) : Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
Carte 2 (intégrée sur serveur Intel de 2006) : Broadcom Corporation NetXtreme BCM5714 Gigabit Ethernet (rev a3)
Carte 2' (intégrée sur serveur AMD de 2006) : Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)
Carte 2" (intégrée sur un pc fixe Intel de 2006) : Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
Carte 2"' (intégrée sur un pc portable Intel de 2006) : Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)
Carte 2"" : Atheros Communications Device 1083 (rev c0) => Atheros AR8151 PCI-E Gigabit Ethernet Controller
Carte 3 (intégrée sur serveur AMD de 2006) : NVIDIA Corporation CK804 Ethernet Controller (rev a3)
Carte 4 (intégrée sur serveur Intel de 2008) : Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
Carte 5 (carte PCI de 2007) : D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10)

Cartes 100 Mb/s uniquement :
Carte 6 (intégrée sur PC fixe Intel de 2008) : Intel Corporation 82562V-2 10/100 Network Connection (rev 02)
Carte 7 (intégrée sur PC fixe Intel de 2008) : Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 01)
Carte 7' (intégrée sur PC portable Intel de 2009) : Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
Carte 8 (intégrée sur PC fixe AMD de 2005) : NVIDIA Corporation MCP51 Ethernet Controller (rev a1)
Carte 8' (intégrée sur Serveur Online de 2009) : Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91)
Carte 8" (intégrée sur serveur OVH de 2007) : VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)
Carte 8"' : Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 01)
Carte 9 (intégrée sur serveur OVH de 2007) : VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)
Carte 10 (intégrée sur PC fixe AMD de 2006  Dell Dimension C521) : Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

Cartes virtuelles (pour les machines virtuelles) :
Carte 11 Red Hat, Inc Virtio network device

on : opération déchargée sur la carte réseau
off : opération réalisée en utilisant le processeur central (CPU)
na : non supporté par le système d'exploitation
Les cartes 1, 2, 3, 5, 6, 7 et 8 sont utilisées avec Ubuntu 12.04 (sortie en 2012)
La carte 4 est utilisée avec Ubuntu 8.04 (sortie en 2008)
La carte 9 est utilisée avec Ubuntu 10.04 (sortie en 2010)
La carte 10 est utilisée avec Ubuntu 11.04 (sortie en 2011)
La carte 11 est utilisée avec Debian

Carte N°                    : 1   2   3   4   5   6   7   8   9   10  11
rx-checksumming             : on  on  on  on  on  on  on  off off off on 
tx-checksumming             : on  on  on  on  off on  off off off off on 
scatter-gather              : on  on  on  on  off on  off off off off on 
tcp-segmentation-offload    : on  on  on  on  off on  off off off off on 
udp-fragmentation-offload   : off off off off off off off off off off on 
generic-segmentation-offload: on  on  on  off off off on  off off off on 
generic-receive-offload     : on  on  on  na  on  on  on  on  off off off
large-receive-offload       : off off off na  off off off off off off off
rx-vlan-offload             : on  on  off na  on  on  on  off na  off na 
tx-vlan-offload             : on  on  off na  on  on  on  off na  off na 
ntuple-filters              : off off off na  off off off off na  off off
receive-hashing             : on  off off na  off off off off na  off off


Bon, c'est un peu la loose pour la carte réseau N°6 utilisée sur le serveur OVH SuperPlan d'avoir une carte VIA Technologies 100 Mb/s avec aucune accélération matérielle !
La carte N°1 est celle du serveur de https://lafibre.info

J'ai remarqué qu'un bonding de deux carte n°1 fait passer "large-receive-offload" de off à on  et "receive-hashing" de on à off sur l'interface de bonding

corrector

  • Invité
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #2 le: 21 juin 2012 à 22:58:14 »
Le déchargement des checksums est une évidence : c'est un calcul standard, bourrin (qui nécessite de toucher beaucoup de mémoire), qui est bon ou faux.

Le déchargement de choses qui nécessitent des choix de stratégie, qui sont complexes, qui peuvent être plus ou moins bons est moins évident.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 5 971
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #3 le: 22 juin 2012 à 06:53:34 »
Salut Vivien,

Est-ce que tu as une idée de combien de "taux d'utilisation de CPU" tu gagnes avec ce genre d'accélération matérielle, à pleine charge (100Mb/s)? Est-ce que c'est significatif?

Leon.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #4 le: 22 juin 2012 à 07:53:23 »
D’après ce que j'ai lu, sans cette accélération, on considère que 1 Mb/s prend 1 Hz de CPU.
Un Trafic a 2 Gb/s consomme donc 2 Mhz.

Le problème n'est pas pour les cartes réseau 100 Mb/s mais pour les serveurs devant délivrer 1Gb/s ou plus car cette puissance CPU pourrait être utilisée pour 'autre choses (Apache, PHP, ...)

Cela change les captures Wireshark (pas besoin de Linux, Windows 7 utilise aussi TCP offload engine, une capture Wireshark sur la plupart du matériel te montrera que les checksum ne sont plus calculés en émission)

Il va y avoir une suite a ce post. Les différences de performances observées entre les deux serveurs de https://testdebit.info/ pour les connexions Orange FTTH, câble avec TAS,... seraient liées à une des optimisations déchargée sur la carte réseau. (et prendre un vieux noyau empêche cette décharge, d'où les bonnes performances du Noyau linux 2.6.24).

corrector

  • Invité
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #5 le: 26 juin 2012 à 01:25:56 »
Si je comprends bien, l'offload du checksum aide pour tous les paquets, mais l'offload de la segmentation n'aide que pour le trafic sortant.

Mais la complexité de la pile réseau augmente fortement, avec deux couches TCP superposées, et deux fois plus de code pouvant contenir des bugs. En plus une de ces couches, celle en dessous (celle que voient les autres machines) est du code de driver qui est souvent très fermé, et toujours moins testé que le code de l'OS.

On devrait plutôt faire des efforts pour augmenter la MTU sur Internet!!!

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #6 le: 26 juin 2012 à 08:53:02 »
Non, certaines carte réseau sont capable de le faire en émission et en réception :
- generic-segmentation-offloa = Déchargement de la segmentation d'un gros paquet TCP en plusieurs petits (en émission)
- generic-receive-offload = Déchargement en fusionnant des petits paquets TCP reçus du réseau en un gros paquet pour le système (c'est donc en réception)
En réception, les paquets qui se suivent reçus dans un intervalle de temps assez court sont agrégés pour en faire des gros bloc transmis au système d'exploitation.

La partie TCP/IP est assez limitée mais certains constructeurs ont imaginé une externalisation complète de TCP/IP dans la carte réseau. Linux s'est toujours refusé ce principe et aucun support n'est offert dans le noyau mais certains constructeurs ont réalisé de patch horrible (il faut modifier beaucoup de choses) pour permettre de sortir TCP/IP du noyau. Effectivement il y a des problématiques de sécurité en sortant TCP/IP sur la carte réseau.

=> http://www.linuxfoundation.org/collaborate/workgroups/networking/toe

corrector

  • Invité
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #7 le: 26 juin 2012 à 09:14:42 »
Citer
Resource-based denial-of-service attacks

If an attacker can discover the TOE NIC model in use, they can use this information to enable resource-based algorithmic attacks. For example, a SYN flood could potentially use up all TOE resources in a matter of seconds. The TOE NIC will either stop accepting connections (complete DoS), or will constantly bounce back to the software net stack.
Beaucoup des arguments avancés concernant le support et le cycle de vie peuvent aussi (plus ou moins) être appliqués aux autres cartes et au fait de mettre plus d'intelligence dedans (notamment la carte graphique).

Mais ces autres périphériques ne sont pas directement exposés à l'extérieur (enfin sauf la carte graphique avec OpenGL ou assimilé - c'est d'ailleurs un souci de sécurité, notamment au niveau du déni de service).

Citer
Eliminates global system view

With TOE, the system no longer has a complete picture of all resources used by network connections. Some connections are software-based, and thus limited by existing policy controls (such as per-socket memory limits). Other connections are managed by TOE, and these details are hidden. As such, the VM cannot adequately manage overall socket buffer memory usage, TOE-enabled connections cannot be rate-limited by the same controls as software-based connections, per-user socket security limits may be ignored, etc.

Linux has several TCP Congestion Control algorithms available. For TOE connections, this would no longer be true, all the congestion control would be done by proprietary vendor specific algorithms on the card
C'est un argument particulièrement fort : ce n'est pas une question conjoncturelle, de confiance ou politique, c'est un argument technique imparable. TCP est complexe et nécessite un paramétrage fin.

Enfin : augmenter significativement la MTU permettrait de résoudre ce soucis de charge CPU.

seb

  • Pau Broadband Country (64)
  • Abonné SFR fibre FttH
  • *
  • Messages: 515
  • FTTH 1 Gbps sur Pau (64)
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #8 le: 26 juin 2012 à 14:31:50 »
TOE : c'est pas le truc qui fait qu'un système Solaris complètement paniqué continue de répondre au ping comme si de rien n'était ? ^^

corrector

  • Invité
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #9 le: 26 juin 2012 à 20:50:04 »
Ils vont finir par coller un OS complet dans la carte Ethernet.

À moins qu'ils soient trop occupés à en mettre en un en guise de BIOS.
« Modifié: 27 avril 2013 à 16:34:43 par corrector »

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #10 le: 03 août 2013 à 11:29:39 »
Et si la latence n'est pas une priorité , on peut aussi diminué le nombre d'interruptions hardware en jouant avec l' interrupt coalescence (ethtool -c eth0) de la carte réseau (si celle la supporte ca evidemment).

Mastah

  • Abonné Orange Fibre
  • *
  • Messages: 292
  • XGS-PON et G-PON
TCP offload engine - Segmentation réalisée par la carte réseau
« Réponse #11 le: 03 août 2013 à 11:49:43 »
Je crois que sur des system type freebsd c'est un peu plus galère que ça