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

[Daniel Cordey]

Le 29/09/2024 à 11:18, Marc SCHAEFER via gull a écrit :
> 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)

J'avais souvenir que les CPUs étaient saturés avec une utilisation 
intensive de connexions à 10 Gb/s. C'était sans doute avec les premières 
cartes de ce type que n'avaient, sans doute, pas ces modes intégrés. 
C'est probablement à la suite de la montée en puissance des cartes (pour 
du 25 Gb/s et plus) que l'on a vu éclore cette pratique destinée à 
décharger le CPU et le bus PCIE et mémoire. Ça me semble logique. 
D'ailleurs, je vois qu'il existe maintenant des cartes pour faire 2x200 
ou 400 Mb/s. Sans cette émulation je pense que l'on aurait des problèmes 
de performance.

Oui, "violation" du modèle ISO, mais ça fait très longtemps que le 
modèle TCP/IP est destiné à répondre aux besoins spécifiques de ce 
protocole, tout en se reposant sur les standards établis. C'est une 
petite "entorse", mais qui évite justement des problèmes de congestion 
lorsque l'on monte en bande passante. Il y a aussi des réflexions qui 
sont menées pour éviter ces problèmes de performance, tel que que TCP 
Fast Open, QUIC, etc. Mais les réflexions vont au-delà des simples 
problèmes de performance. Il y a aussi des questions de sécurité, de 
SDN, d'intégration de nouvelles technologies (5G, Iot, etc.), etc. Il y 
a donc fort à parier que les cartes du futur vont intégrer de plus en 
plus de firmware destiné à soulager le(s) CPU(s) de la gestion de 
certains protocoles, et peut-être des choses comme TLS, HTTP3, etc. On 
verra.

Le "debuging" des problèmes de connexions dans un environnement cloud et 
utilisant massivement Kubernetes et le SDN va devenir... assez 
intéressant. :-)

dc

> 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
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

-- 
----------
Daniel Cordey
Mail :dc at pxcluster.com
Tel Esp : +34 623 517-666
Tel And : +376 692-550
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20240930/f74c7f5e/attachment.html>