<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<p><br>
</p>
<div class="moz-cite-prefix">Le 29/09/2024 à 11:18, Marc SCHAEFER
via gull a écrit :<span style="white-space: pre-wrap">
</span></div>
<blockquote type="cite" cite="mid:ZvkbcjR8FmgAuKXj@alphanet.ch">
<pre wrap="" class="moz-quote-pre">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)</pre>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>Le "debuging" des problèmes de connexions dans un environnement
cloud et utilisant massivement Kubernetes et le SDN va devenir...
assez intéressant. :-)<br>
</p>
<p>dc<br>
</p>
<blockquote type="cite" cite="mid:ZvkbcjR8FmgAuKXj@alphanet.ch">
<pre wrap="" class="moz-quote-pre">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: <a class="moz-txt-link-freetext"
href="https://www.ibm.com/docs/en/linux-on-systems?topic=offload-tcp-segmentation">https://www.ibm.com/docs/en/linux-on-systems?topic=offload-tcp-segmentation</a>
Evidemment, c'est aussi valable en virtualisation
<a class="moz-txt-link-freetext"
href="https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-FB4F8DB7-B4AC-4442-9B0B-B776F0C7BCCB.html">https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-FB4F8DB7-B4AC-4442-9B0B-B776F0C7BCCB.html</a>
(*) le firmware, souvent
_______________________________________________
gull mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:gull@forum.linux-gull.ch">gull@forum.linux-gull.ch</a>
<a class="moz-txt-link-freetext"
href="https://forum.linux-gull.ch/mailman/listinfo/gull">https://forum.linux-gull.ch/mailman/listinfo/gull</a></pre>
</blockquote>
<pre class="moz-signature" cols="72">--
----------
Daniel Cordey
Mail : <a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:dc@pxcluster.com">dc@pxcluster.com</a>
Tel Esp : +34 623 517-666
Tel And : +376 692-550</pre>
<lt-container></lt-container>
</body>
</html>