[gull] ksoftirqd congestionne a ~500Ko/s (Ubuntu 22.04)

Marc SCHAEFER schaefer at alphanet.ch
Sun Sep 29 11:18:42 CEST 2024


Hello,

et quelques infos sur TCP/TSO: (sans rapport avec notre sujet):

Très généralement, il y a deux façons de faire des I/Os:

   - traiter une interruption pour chaque trame, voire parfois
     par liste de trames (scatter/gather DMA)
   - faire du polling

et il est aussi possible de combiner les approches.

Les cartes Ethernet modernes permettent de décharger le CPU en traitant
toutes sortes de chose dans la carte:

   - calcul des checksums TCP, UDP et IP
   - émulation du protocole TCP (scatter-gather)

C'est surtout l'émulation du protocole TCP (en jolie violation du modèle
en couche OSI), le TCP/TSO, qui permet à l'OS de limiter les
interruptions.  En effet, la carte présente à l'OS un MTU bien plus
grand que le MTU d'Ethernet, le kernel prépare des paquets TCP de
grandes tailles, et ceux-ci sont ensuite découpés par la carte (*),
qui exécute le véritable protocole TCP, et génère les confirmations
factices pour le TCP du kernel.

Exemple: un paquet d'environ 8000 octet est envoyé plutôt que 5 paquets,
soit en comptant les confirmations un gain de 10x en moins
d'interruptions.

Symptôme: wireshark montre des gros paquets de taille supérieure
au MTU usuel Ethernet; mais entre les 2 machines les routeurs
voient les tailles réelles (MTU 1500).

Initialement, il y avait parfois des bugs de firmware: j'avais sorti
l'analyseur en mode bridge pour voir ce qui se passait.

Activer TSO: https://www.ibm.com/docs/en/linux-on-systems?topic=offload-tcp-segmentation

Evidemment, c'est aussi valable en virtualisation
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-FB4F8DB7-B4AC-4442-9B0B-B776F0C7BCCB.html

(*) le firmware, souvent


More information about the gull mailing list