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@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
-- ---------- Daniel Cordey Mail :d...@pxcluster.com Tel Esp : +34 623 517-666 Tel And : +376 692-550
_______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
