Linux 7.3 : BIG TCP s’étend aux tunnels réseau, tandis que l’IA submerge les mainteneurs

L’objectif est de réduire le coût du traitement paquet par paquet, et non de modifier la MTU configurée sur la liaison. Le bénéfice peut donc aussi concerner des systèmes utilisant une MTU standard ou dépourvus de prise en charge matérielle du déchargement des tunnels : le logiciel manipule alors moins de paquets, mais plus volumineux, en interne.

Une série de correctifs consacrée à BIG TCP explique le travail nécessaire en profondeur. Plusieurs chemins réseau supposaient que la longueur des paquets resterait inférieure à 64 Kio ou pouvait être stockée dans des champs de 16 bits. Ces hypothèses ont dû être corrigées pour prendre en charge les flux BIG TCP IPv4 et IPv6 dans VXLAN et Geneve.

Moins de contention autour du verrou RTNL

Autre changement important : les opérations sur les règles de la base d’informations de transfert, ou FIB, comme RTM_NEWRULE et RTM_DELRULE, dépendent moins du verrou global RTNL.

Cette évolution vise les systèmes qui administrent simultanément de nombreux espaces de noms réseau. En limitant un point de sérialisation global, le noyau peut laisser davantage d’opérations progresser en parallèle entre ces environnements isolés.

Les informations disponibles confirment l’objectif architectural de cette modification, mais ne fournissent pas de mesure fiable et précise du gain en IPv4 ou en IPv6. Il serait donc abusif d’annoncer un pourcentage ou un multiplicateur de performances. Le résultat dépendra de la charge, du nombre d’espaces de noms et de la configuration de la machine.

De nouveaux pilotes et plusieurs améliorations ciblées

La fusion réseau apporte également des évolutions matérielles et protocolaires :

• Le pilote Morse Micro mm81x prend en charge des appareils S1G à longue portée, tandis qu’un nouveau pilote NXPWIFI fait son apparition.
• Une première infrastructure Intel iXD cible la fonction PIC du plan de contrôle Intel, sur les IPU Intel E2100 et générations suivantes ainsi que les FNIC.
• MPTCP améliore son comportement sous pression mémoire extrême, notamment en supprimant des éléments de sa file de réception des paquets arrivés dans le désordre.
• La fusion contient aussi de nombreux correctifs et travaux supplémentaires pour les réseaux filaires et sans fil.

Ces changements ont été intégrés au travail de développement de Linux 7.3 pendant la fenêtre de fusion. Ils ne correspondent pas à une version stable déjà publiée.

Pourquoi les mainteneurs se disent-ils « complètement dépassés » ?

Dans leur demande de fusion, Jakub Kicinski et Paolo Abeni indiquent avoir intégré 632 correctifs net et 648 correctifs net-next, soit 1 280 changements au total. Ce décompte ne reflète toutefois pas toute la charge de travail : chaque contribution doit encore être lue, vérifiée, testée et parfois discutée avec son auteur.

Leur estimation « rapide et approximative » est particulièrement révélatrice : entre un tiers et la moitié des correctifs net-next semblent être des changements de faible priorité — corrections mineures, nettoyages ou clarifications — générés ou assistés par l’IA.

L’afflux ne se limite pas à cette seule fusion. En neuf jours, le sous-système réseau a reçu 405 contributions portant l’étiquette

[PATCH net]

[PATCH net-next]

Le problème ne tient donc pas uniquement à la capacité de l’IA à écrire du code. Les outils peuvent aussi produire à très faible coût des explications plausibles, des rapports de bogues et des demandes de revue. Les mainteneurs humains doivent ensuite déterminer si chaque proposition est nécessaire, correcte, sûre et suffisamment utile pour être intégrée.

Des modèles de langage pour absorber le travail répétitif

Les mainteneurs expliquent avoir obtenu, avec le soutien financier de Meta, l’accès et le budget nécessaires pour faire examiner les correctifs par plusieurs grands modèles de langage. L’objectif immédiat est de repérer une partie des changements faibles ou « hallucinés » avant qu’ils ne mobilisent davantage de temps humain.

Ils souhaitent également confier aux modèles des tâches plus routinières, notamment :

• la gestion des files Patchwork ;
• les retours sur les erreurs fréquentes de procédure lors de l’envoi d’un correctif ;
• la modification des messages de commit ;
• et, éventuellement, l’application de correctifs déjà revus et marqués par des personnes de confiance.

Cette approche présente les modèles de langage comme des assistants de flux de travail, et non comme des remplaçants des responsables des sous-systèmes. La distinction est essentielle pour le code du noyau sensible à la concurrence.

Les mainteneurs soulignent notamment les chemins d’exécution rares, comme ceux liés aux erreurs PCIe ou aux délais d’expiration. Des courses critiques peuvent dépendre d’un enchaînement temporel peu fréquent, difficile à reproduire et encore plus difficile à démontrer comme impossible. Une revue par LLM peut signaler des motifs suspects, mais elle ne permet pas d’établir de manière fiable la correction de toutes les interleavings possibles.

Ce que l’on ne sait pas encore

Les sources disponibles ne donnent pas de date attendue pour

Linux 7.3-rc1

De même, les modifications de RTNL doivent améliorer le passage à l’échelle des opérations parallèles sur les règles FIB entre plusieurs espaces de noms réseau, mais aucun chiffre de performance IPv4 ou IPv6 suffisamment étayé n’est disponible. La conclusion prudente est donc architecturale : en réduisant la contention sur un verrou global, le noyau devrait offrir davantage de marge aux charges très parallèles, sans que l’ampleur du gain puisse encore être quantifiée.