La Fibre

Télécom => Logiciels et systèmes d'exploitation => Linux Linux => Discussion démarrée par: vivien le 21 juin 2012 à 22:37:49

Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 21 juin 2012 à 22:37:49
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.

(https://lafibre.info/testdebit/pcap/201206_TCP_offload_engine_desactive.png)

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.

(https://lafibre.info/testdebit/pcap/201206_TCP_offload_engine_active.png)

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 (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...
(https://lafibre.info/testdebit/pcap/201206_TCP_offload_engine_IPv4_1.png)

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é) !
(https://lafibre.info/testdebit/pcap/201206_TCP_offload_engine_IPv4_2.png)

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

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)
(https://lafibre.info/testdebit/pcap/201206_TCP_offload_engine_IPv6_2.png)


Documentation sur le TCP offload engine :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/materiel/201608_dell_broadcom_toe_key.png) (https://lafibre.info/images/materiel/201608_dell_broadcom_toe_key.pdf)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien 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 (http://www.broadcom.com/products/Ethernet-Controllers/Enterprise-Server/BCM5714S) Gigabit Ethernet (rev a3)
Carte 2' (intégrée sur serveur AMD de 2006) : Broadcom Corporation NetXtreme BCM5721 (http://www.broadcom.com/products/BCM5721) Gigabit Ethernet PCI Express (rev 11)
Carte 2" (intégrée sur un pc fixe Intel de 2006) : Broadcom Corporation NetXtreme BCM5751 (http://www.broadcom.com/products/BCM5751) Gigabit Ethernet PCI Express (rev 01)
Carte 2"' (intégrée sur un pc portable Intel de 2006) : Broadcom Corporation NetXtreme BCM5752 (http://www.broadcom.com/products/Ethernet-Controllers/Enterprise-Client/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 (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
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: corrector 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.
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Leon 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.
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien 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/ (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).
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: corrector 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!!!
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien 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 (http://www.linuxfoundation.org/collaborate/workgroups/networking/toe)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: corrector 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.
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: seb 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 ? ^^
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: corrector 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.
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: kgersen 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).
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Mastah 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
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: kgersen le 03 août 2013 à 15:23:24
Je crois que sur des system type freebsd c'est un peu plus galère que ça
pour FreeBSD:
ifconfig | grep -i runningpour avoir le nom de l'interface. Celui ci a par défaut pour racine le nom du driver.
si c'est l'interface est em0 par exemple, alors le driver est 'em' (autre exemples de drivers: igb, bce)
Ensuite "sysctl hw.<driver>" ("sysctl hw.em" dans notre exemple) pour voir les paramètres possibles qu'on peut régler avec loader(8 )/loader.conf(5) au boot.
Certains paramètres sont modifiable en live avec sysctl:
sysctl dev.<driver>.<instance> pour voir la liste (donc dev.em.0 dans notre cas).
et
sysctl dev.<driver>.<instance>.<parametre>=<valeur> pour changer un parametre.

Un man 4 du driver ('man 4 em (http://www.freebsd.org/cgi/man.cgi?query=em&apropos=0&sektion=4&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html)' dans notre exemple) donne les explications pour chaque parametre.
bce (man 4 bce (http://www.freebsd.org/cgi/man.cgi?query=bce&apropos=0&sektion=4&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html)) est un exemple qui supporte le TCP Offload Engine et l'Interrupt coalescing.

Enfin en théorie car en pratique j'ai jamais joué en prod avec ces paramètres de cartes ... ;)
Les cartes Intel récentes ont une adaptation automatique pour éviter de flooder des interruptions (Adaptive Interrupt Moderation).
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: kgersen le 04 août 2013 à 08:38:54
petite précision sur le vocabulaire pour éviter les confusions:

TOE - TCP Offload Engine
et
TSO - TCP Segmentation Offload

ne sont pas du tout la meme chose. Cette discussion a pour titre "TCP offload engine - Segmentation réalisée par la carte réseau" mais parle de TSO.

Souvent on mélance les 2 notions, il ne faudrait pas...

TOE n'est pas supporté sur Linux et n'est pas globalement accepté comme une bonne technique. Le principe de TOE est que la carte sous traite bien plus de choses, notamment l'ouverture des connections, l'envoi des ack ou la fermeture des connections. TSO est une sous partie de TOE d'ou souvent la confusion de langage.
Voir le wikipedia de TOE pour plus d'info: https://en.wikipedia.org/wiki/TCP_offload_engine (https://en.wikipedia.org/wiki/TCP_offload_engine)

Quelques définitions sur les autre options 'offload'(-k) de ethtool:

rx-checksumming: laisse le soin a la carte de vérifier la checksum. rejete le packet si pas la somme est pas bonne. le cpu n’est pas derangé pendant cette opération. gains cpu approx: 5% a 1500 MTU, 15% a 9000 MTU

tx-checksumming: le cpu met une valeur bidon pour la checksum et la carte calcule et met la bonne valeur avec d’envoyer le packet sur le réseau. gains approx idem rx.

scatter-gather: aussi appelé Vectored I/O. permet de d’échanger les données en les fragmentant/assemblant. En lecture (carte->cpu) on ‘scatter’ en eclatant un morceau de mémoire contigue (dans la carte) en plusieurs endroits différents dans la RAM via DMA. En écriture (cpu->carte) on ‘gather’ en récupérant des morceaux a différents endroits via DMA et en les combinant dans un seul morceau de mémoire dans la carte. Typiquement l’entete du paquet est a un endroit, les données utiles (le payload) a un autre et ca scatter dans un sens et gather dans l’autre. On peut combiner ca avec “page flip” (changement de page dans le systeme de gestion de mémoire virtuelle)  pour éviter de copier le payload en mémoire et le mapper directement avec le buffer de l'application par exemple. Avantage: moins de besoin mémoire (moins de besoin de gros bouts contiguës), moins de copies mémoires par le cpu donc gains de mémoire et de cycles cpu.

TSO - tcp segmentation offload: expliqué au début par Vivien. C'est dispo dans Linux depuis la 2.6.16.10. La carte doit supporter ca.

UFO - udp fragmentation offload: principe du TSO mais appliqué a UDP.

LRO - large receive offload : en gros l’inverse du TSO, rassemble plusieurs packets dans la carte avant de passer un seul gros packet au cpu. y’a 2 variantes: une software dans le driver, une hardware directement dans la carte.

GSO - generic segmentation offload :  comme TSO  mais géré par le kernel si la carte ne supporte pas TSO. Le principe est qu’on retarde le plus possible la segmentation. C'est souvent off par défaut quand TSO est on car c'est redondant. Mais ca peut aussi servir a améliorer autre chose que TCP contrairement a TSO qui n'est que pour TCP.

generic-receive-offload : le pendant en reception de GSO.
large segment offload: c'est le terme/concept générique commun a TSO, GSO, USO et LRO (en réception).

ntuple-filters : surtout pour les machines multi-core/multi-cpu. Principe d’avoir plusieurs queues de traitement dans la carte. Des regles style regles de firewall (style source, dest, port, proto) permet d’aiguiller les packets dans des queues différentes. Ensuite une queue peut etre apairé avec toujours le meme core du CPU et une IRQ propre, ce core gérant aussi l'application qui utilise ce flux (ca evite les changements de contexte entre cores notamment et une meilleur affinité sur les cpu).

Apres y'a de plus en plus d'options avec le temps. Surtout car ipv6 arrivant a maturité, certaines cartes sont mixtes d'autre pas donc les options se dédoublent voir triplent (options pour ipv4, options pour ipv6, options pour les 2, etc).
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 04 août 2013 à 10:19:18
Merci !

ToE si c'est la carte qui gère les connexions TCP sous Windows, cela ne pose pas de problème de sécurité ? Le gros de la pile TCP/IP est dans la carte réseau, plus dans le système d’exploitation ! La carte réseau connait la liste des ports sur lesquels elle doit accepter les connexions TCP ?

Pour donner un exemple des options de ethtool -k sur un matériel serveur standard sans virtualisation :

Ubuntu server 13.04 64bits sur un serveur Dell PowerEdge R210 (Xeon X3450 @2.67GHz) :

# uname -r
3.8.0-27-generic

# lspci | grep Ethernet
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)

# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]

Ubuntu server 12.04 64bits sur un serveur Dell PowerEdge R210 (Xeon X3450 @2.67GHz) :
# uname -r
3.2.0-51-generic

# lspci | grep Ethernet
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on

Ubuntu server 8.04 64bits sur un serveur IBM (Xeon E5430 @2.66GHz) :
~# uname -r
2.6.24-32-server

# lspci | grep Ethernet
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: corrector le 04 août 2013 à 13:10:33
ToE si c'est la carte qui gère les connexions TCP sous Windows, cela ne pose pas de problème de sécurité ?
Le gros de la pile TCP/IP est dans la carte réseau, plus dans le système d’exploitation !
De façon générale, on peut craindre un bug dans le driver, dans le micro-code (fermé)...

Et aussi des pessimisations, des interactions indésirables...

La carte réseau connais la liste des ports sur lesquels elle doit accepter les connexions TCP ?
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: BadMax le 05 août 2013 à 18:38:45
Merci !

ToE si c'est la carte qui gère les connexions TCP sous Windows, cela ne pose pas de problème de sécurité ? Le gros de la pile TCP/IP est dans la carte réseau, plus dans le système d’exploitation ! La carte réseau connait la liste des ports sur lesquels elle doit accepter les connexions TCP ?

Ca va etre simple d'expliquer le modèle OSI avec ça...

"Donc un switch L3 est un switch qui normalement ne fait que traiter les informations en couche 2. Mais comme il est L3 il traite la couche 3 comme un routeur mais ça reste un switch. La carte réseau du PC traite la couche 1 et 2 mais si y'a TOE activé elle traite aussi les couches 3 et 4. Une box ADSL sait traiter toutes les couches 1/2/3/4 car c'est à la fois un modem, un switch, un routeur et un firewall. Si les couches sont sales il faut les changer mais vous pouvez aussi utiliser des couches lavables."
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 07 octobre 2013 à 10:18:50
Un exemple où la désactivation de tso/gso fait perdre du débit :

J'ai un ping de 103ms (netem +100ms) entre mon PC 1g/b sous Ubuntu 13.04 (4Go ram, Linux 3.8 64bits configuration par défaut) et testdebit.info

Serveur Linux 3.8 64bits avec configuration par défaut :
$ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
100%[=========>] 1 000 000 000 26,2MB/s   ds 41s   
2013-10-07 10:08:10 (23,1 MB/s) - «/dev/null» enregistré [1000000000/1000000000]

Serveur Linux 3.8 32bits avec TSO/GSO désactivé :
$ wget -O /dev/null http://2.testdebit.info/fichiers/1000Mo.dat (http://2.testdebit.info/fichiers/1000Mo.dat)
100%[=========>] 1 000 000 000 17,5MB/s   ds 59s   
2013-10-07 10:11:13 (16,2 MB/s) - «/dev/null» enregistré [1000000000/1000000000]

Serveur Linux 3.8 64bits avec TSO/GSO désactivé :
$ wget -O /dev/null http://3.testdebit.info/fichiers/1000Mo.dat (http://3.testdebit.info/fichiers/1000Mo.dat)
100%[=========>] 1 000 000 000 17,0MB/s   ds 64s   
2013-10-07 10:10:08 (14,9 MB/s) - «/dev/null» enregistré [1000000000/1000000000]

Serveur Linux 2.6.24 avec la configuration par défaut :
$ wget -O /dev/null http://bouygues.testdebit.info/fichiers/1000Mo.dat (http://bouygues.testdebit.info/fichiers/1000Mo.dat)
100%[=========>] 1 000 000 000 26,2MB/s   ds 42s   
2013-10-07 10:08:58 (22,7 MB/s) - «/dev/null» enregistré [1000000000/1000000000]
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 30 octobre 2013 à 10:16:07
De nouvelles options sont disponibles avec Ubuntu 13.10 et le noyau 3.11 : ce sont les 6 lignes en gras

# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
   tx-checksum-ipv4: on
   tx-checksum-ip-generic: off [fixed]
   tx-checksum-ipv6: on
   tx-checksum-fcoe-crc: off [fixed]
   tx-checksum-sctp: off [fixed]
scatter-gather: on
   tx-scatter-gather: on
   tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
   tx-tcp-segmentation: on
   tx-tcp-ecn-segmentation: on
   tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]

fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]


C'est Ubuntu server 13.10 64bits sur un serveur Dell PowerEdge R210 (Xeon X3450 @2.67GHz)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 30 octobre 2013 à 11:32:06
Les premiers tests montrent encore des changements au niveau TCP/IP dans des conditions difficiles (très haut débit ou ping important)

Et cette fois-ci avec Linux 3.11, désactiver TSO/GSO dégrade notablement les performances, alors qu'avec les noyaux précédents (surtout le 3.8 avec lequel j'ai fais pas mal de test désactiver TSO/GSO améliore généralement le débit)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Bensay le 30 octobre 2013 à 12:12:56
De nouvelles options sont disponibles avec Ubuntu 13.10 et le noyau 3.11 : ce sont les 6 lignes en gras

# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
   tx-checksum-ipv4: on
   tx-checksum-ip-generic: off [fixed]
   tx-checksum-ipv6: on
   tx-checksum-fcoe-crc: off [fixed]
   tx-checksum-sctp: off [fixed]
scatter-gather: on
   tx-scatter-gather: on
   tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
   tx-tcp-segmentation: on
   tx-tcp-ecn-segmentation: on
   tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]

fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]


C'est Ubuntu server 13.10 64bits sur un serveur Dell PowerEdge R210 (Xeon X3450 @2.67GHz)

Bonjour Vivien,

Existe t'il un post une section ou une URL ou c'est paramètres et leurs fonctions/utilités sont expliquée ?

Cdt

Bensay
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: kgersen le 30 octobre 2013 à 14:39:38
Souvent la man page d'ethtool est mise a jour  pour expliquer (succinctement j'avoue) ces options.

Concernant ces nouvelles options, a première vue les 3 "tx-*-segmentation" concernent le GSO pour certains types de paquet (tunnel GRE, tunnel TNL sur UDP et MPLS). L'idee est que la carte qui supporte ca est sans doute capable de fragmenter elle meme un gros paquet GRE en plusieurs paquets tout en préservant la cohérence du flux encapsulé.

Les 3 options "vlan-stag" au vue de leurs noms concernent le support matériel du 802.1ad (https://fr.wikipedia.org/wiki/IEEE_802.1ad) (Q in Q) a savoir l'utilisation de VLANs dans un VLAN, notamment utile pour les providers qui veulent transporter les VLANs de leur cllents. "stag" correspondant au S-TAG dit Service Tag. Ces options permettraient donc a la carte elle-meme d'inserer le s-tag en emission (tx-vlan-stag-hw-insert) et de filter puis enlever le s-tag en réception avec les 2 autres options.  A priori ca s’adresse plus a des équipements type CPE ou de bordure.
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 08 août 2014 à 10:04:41
Dans le nouveau noyau Linux 3.16, sortie le 3 août 2014 (et qui sera intégré dans Ubuntu 14.10 qui sort le 23 octobre 2014), il y a une émulation logicielle de la TCP Segmentation Offload (TSO) a été ajoutée au noyau et permet à des SoCs d'augmenter leur débit maximal de 16% à 54% tout en réduisant l'utilisation CPU de 40% dans un test de performance basé sur HTTP (commits : 1, 2). La TSO consiste normalement à envoyer l'ensemble des données à transmettre à la carte réseau et laisser celle-ci découper les paquets. Cela permet de limiter la consommation CPU sans perdre de performance.

Source : Linux FR (http://linuxfr.org/news/sortie-de-linux-3-16)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Harvester le 08 août 2014 à 10:55:38
A regarder les commits, ça ne semble concerner que 2 drivers actuellement, donc pas de révolution à venir sur les téléphones et appareils mobiles pour l'instant, peut être dans la prochaine itération du noyau...
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: jack le 08 août 2014 à 11:06:56
Vivien, tu as compris à quoi sert le TSO "émulé logiciellement" ?
Si je ne m'abuse, le TSO déporte la segmentation et le checksum sur la carte réseau, donc c'est bénéfique
Sans TSO (avant, donc), c'est le kernel qui se charge de couper et de compter
Avec le TSO émulé, c'est le kernel qui se charge de couper et de compter

J'ai surement raté un morceau  :(
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Harvester le 08 août 2014 à 12:13:06
Sauf qu'avant, apparemment, le kernel ne se comportait pas TSO-style pour le découpage et l'envoi des packets. Là, pour les drivers qui le supporte, tu émules un TSO logiciel, ce qui ne te fait rien gagner en terme de consommation CPU (il indique dans son commit 30% d'usage avec ou sans), mais permet de gagner en débit, car comme pour le TSO, tu envoies plus de packets d'un coup.

C'est comme ça que je le comprends à la lecture des commits et de la LKML, n'hésitez pas à me corriger...

EDIT:
Citer
Add SG and software TSO support for FEC. This feature allows to improve outbound throughput performance. Tested on imx6dl sabresd board, running iperf tcp tests shows: * 82% improvement comparing with NO SG & TSO patch

$ ethtool -K eth0 sg on $ ethtool -K eth0 tso on [ 3] local 10.192.242.108 port 35388 connected with 10.192.242.167 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 3.0 sec 181 MBytes 506 Mbits/sec * cpu loading is 30%

$ ethtool -K eth0 sg off $ ethtool -K eth0 tso off [ 3] local 10.192.242.108 port 52618 connected with 10.192.242.167 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 3.0 sec 99.5 MBytes 278 Mbits/sec

FEC HW support IP header and TCP/UDP hw checksum, support multi buffer descriptor transfer one frame, but don't support HW TSO. And imx6q/dl SOC FEC Gbps speed has HW bus Bandwidth limitation (400Mbps ~ 700Mbps), imx6sx SOC FEC Gbps speed has no HW bandwidth limitation.

The patch set just enable TSO feature, which is done following the mv643xx_eth driver.

Test result analyze: imx6dl sabresd board: there have 82% improvement, since imx6dl FEC HW has bandwidth limitation, the performance with SW TSO is a milestone.

Addition test: imx6sx sdb board: upstream still don't support imx6sx due to some patches being upstream... they use same FEC IP. Use the SW TSO patches test imx6sx sdb board in internal kernel tree: No SW TSO patch: tx bandwidth 840Mbps, cpu loading is 100%. SW TSO patch: tx bandwidth 942Mbps, cpu loading is 65%. It means the patch set have great improvement for imx6sx FEC performance.

https://gitorious.org/linux-can/linux-can-next/commit/fba0e1a3cfcc1d61e593f97650e18931a2aa1fc8

A final ça réduit quand même bien les cycles bouffés :)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: jack le 08 août 2014 à 13:13:52
Tu veux dire qu'avant, le kernel prenait chaque paquet un par un
Et après, il envoye des gros bloc à un module plus spécialisé ?

Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Harvester le 08 août 2014 à 14:37:52
Non, avant il respectait la MTU pour séparer les paquets, ce qui génère pas mal d'overhead sur des gros fichiers: http://www.linuxjournal.com/content/queueing-linux-network-stack (http://www.linuxjournal.com/content/queueing-linux-network-stack)

Citer
Huge Packets from the Stack

Most NICs have a fixed maximum transmission unit (MTU), which is the biggest frame that can be transmitted by the physical media. For Ethernet, the default MTU is 1,500 bytes, but some Ethernet networks support Jumbo Frames (https://en.wikipedia.org/wiki/Jumbo_frame (https://en.wikipedia.org/wiki/Jumbo_frame)) of up to 9,000 bytes. Inside the IP network stack, the MTU can manifest as a limit on the size of the packets that are sent to the device for transmission. For example, if an application writes 2,000 bytes to a TCP socket, the IP stack needs to create two IP packets to keep the packet size less than or equal to a 1,500 MTU. For large data transfers, the comparably small MTU causes a large number of small packets to be created and transferred through the driver queue.

In order to avoid the overhead associated with a large number of packets on the transmit path, the Linux kernel implements several optimizations: TCP segmentation offload (TSO), UDP fragmentation offload (UFO) and generic segmentation offload (GSO). All of these optimizations allow the IP stack to create packets that are larger than the MTU of the outgoing NIC. For IPv4, packets as large as the IPv4 maximum of 65,536 bytes can be created and queued to the driver queue. In the case of TSO and UFO, the NIC hardware takes responsibility for breaking the single large packet into packets small enough to be transmitted on the physical interface. For NICs without hardware support, GSO performs the same operation in software immediately before queueing to the driver queue.

Ici, l'émulation est bien logicielle et se fait bien au niveau du driver (qui doivent donc être adaptés, d'où ma remarque d'au dessus sur les deux drivers implèmentants la chose), ce qui du coup explique aussi le gain CPU observé (moins de paquets à découper pour respecter la MTU).

Je sais pas si je suis très clair en fait...
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 08 août 2014 à 14:41:19
J'ai bien compris le gain de décharger cette opération à la carte réseau.

Par contre je ne vois pas de gain à faire cette opération logiciellement au niveau du driver ou logiciellement dans la pile TCP/IP.

C'est un gain de CPU, de débit, de latence ou aucun des 3 ?
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: Harvester le 08 août 2014 à 15:01:42
Citer
C'est un gain de CPU, de débit, de latence ou aucun des 3 ?

A la vue des micro-benchs postés dans les commits, CPU et débits (il y en a un dans la partie en gras dans mon édit deux messages au dessus).

En cherchant des détails sur la chose, on tombe sur un post de 2008 sur la mailing list d'OpenWall (distrib orientée serveurs) (!) ici: http://lists.openwall.net/netdev/2008/07/31/14 (http://lists.openwall.net/netdev/2008/07/31/14) qui explique un peu plus clairement la chose:

Citer
If a netdevice does not support hardware GSO, allowing the stack to
use GSO anyway and then splitting the GSO skb into MSS-sized pieces
as it is handed to the netdevice for transmitting is likely still
a win at least as far as CPU usage is concerned, since it reduces
the number of trips through the output path.

This patch enables the use of GSO on any netdevice that supports SG
and hardware checksumming.  If a GSO skb is then sent to a netdevice
that supports SG and checksumming but does not support hardware GSO,
net/core/dev.c:dev_hard_start_xmit() will take care of doing the
necessary GSO segmentation in software.

Donc ce que j'en comprends, c'est qu'avant, on ne profitais pas du SG et du checksumming matériel sans TSO, ce qui est normal. La en émulant le TSO de façon logicielle, on peut en tirer parti, d'où les gains constatés que ce soit en terme de débit ou de conso CPU. Si quelqu'un à une meilleure explication...
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 27 novembre 2017 à 08:34:36
Pour certaines cartes réseaux, le TOE - TCP Offload Engine est proposé en option payante.

Vous avez alors sur la carte mère un petit connecteur RJ11 pour le TOE : (c'est surtout sur des carte mère de serveur Dell commercialisées de 2006 à 2008)

(https://lafibre.info/images/materiel/201711_broadcom_toe_key_1.jpg)


Voici la clef TOE, qui sert juste a prouver que vous avez bien payé :

(https://lafibre.info/images/materiel/201711_broadcom_toe_key_2.jpg)

Le dos :

(https://lafibre.info/images/materiel/201711_broadcom_toe_key_3.jpg)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 27 novembre 2017 à 08:35:57
Voici la clef dans son connecteur :
(https://lafibre.info/images/materiel/201711_broadcom_toe_key_4.jpg)

Pour ceux qui n'ont pas acheté la clef avec le serveur, il est possible de l'acheter ultérieurement :
(https://lafibre.info/images/materiel/201711_broadcom_toe_key_8.jpg)

Il existe aussi des clef iSCSI :

(https://lafibre.info/images/materiel/201711_broadcom_toe_key_7.jpg)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 27 novembre 2017 à 08:40:13
Documentation sur le TCP offload engine :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/materiel/201608_dell_broadcom_toe_key.png) (https://lafibre.info/images/materiel/201608_dell_broadcom_toe_key.pdf)


Le BIOS permet de voir que le TOE est présent, mais que nous n'avons pas payé pour le iSCSI :
(https://lafibre.info/images/materiel/201711_broadcom_toe_key_5.jpg)

Le chip réseau de la carte en question :

(https://lafibre.info/images/materiel/201711_broadcom_toe_key_6.jpg)
Titre: TCP offload engine - Segmentation réalisée par la carte réseau
Posté par: vivien le 27 novembre 2017 à 08:55:37
Le driver permet de paramétrer le TOE :

(https://lafibre.info/images/materiel/201711_broadcom_toe_key_1.png) (https://lafibre.info/images/materiel/201711_broadcom_toe_key_2.png) (https://lafibre.info/images/materiel/201711_broadcom_toe_key_3.png)
(copie d'écran du driver de mai 2008 pour Windows Server 2003)