Linux 7.3 mise sur BIG TCP, un routage plus rapide et la revue de correctifs par IA

La branche réseau destinée à Linux 7.3 se distingue par un double mouvement : elle cherche à mieux passer à l’échelle dans les infrastructures utilisant des tunnels et de nombreux espaces de noms réseau, tout en tentant de répondre à l’afflux de correctifs générés ou aidés par l’intelligence artificielle. Le code a été intégré à la branche principale le 20 août 2026, pendant la fenêtre de fusion ; Linux 7.3 n’est donc pas encore une version stable.

BIG TCP s’étend à VXLAN et Geneve

La nouveauté la plus visible concerne BIG TCP, désormais pris en charge par les pilotes de tunnels UDP VXLAN et Geneve. Le noyau peut traiter en interne des charges utiles dépassant 64 Kio, puis les découper avec GSO et TSO avant leur transmission sur le réseau. L’objectif n’est pas d’envoyer des paquets surdimensionnés, mais de réduire le coût du traitement paquet par paquet dans les chemins de données des réseaux superposés.

Les mesures publiées avec

netperf TCP_STREAM

• avec VXLAN et une MTU standard, le débit passe de 34,44 à 39,56 Gbit/s, soit +14,9 % ;
• lorsque l’accélération matérielle du tunnel est désactivée, VXLAN passe de 21,82 à 29,39 Gbit/s, soit +34,7 % ;
• avec Geneve et une MTU standard, le débit progresse de 37,39 à 40,89 Gbit/s, soit +9,4 %.

Ces chiffres ne constituent pas une promesse de gain universel pour Linux 7.3. Ils correspondent à une configuration précise et dépendent notamment de gso_max_size, gro_max_size, des capacités de la carte réseau, des options d’offload, de la MTU, du type de tunnel et de la charge de travail. Les exploitants devront donc mesurer leur propre infrastructure VXLAN ou Geneve avant d’extrapoler ces pourcentages.

Moins de contention pour les règles de routage

La fusion réduit également la dépendance au verrou global RTNL lors de l’ajout et de la suppression de règles FIB IPv4 et IPv6. Lorsque c’est possible, ces opérations s’appuient désormais sur le mutex associé à fib_rules_ops, ce qui permet davantage de traitement en parallèle. RTNL reste toutefois nécessaire dans certains chemins, notamment lors du fib_unmerge() de la première règle IPv4.

Un test volontairement intensif illustre l’intérêt de cette évolution pour les environnements qui créent et configurent de nombreux espaces de noms réseau en parallèle. La création de 4 096 espaces de noms, avec l’ajout simultané de 1 024 règles dans chacun, passe :

• pour IPv4, de 22,752 à 0,918 seconde, soit environ 24,8 fois plus rapide ;
• pour IPv6, de 35,181 à 1,214 seconde, soit environ 29 fois plus rapide.

Il s’agit d’un scénario synthétique conçu pour faire ressortir la contention des verrous. Ces résultats ne garantissent pas une accélération équivalente du démarrage habituel des conteneurs ni de tous les traitements de routage.

Les mainteneurs débordés par les correctifs liés à l’IA

L’autre histoire de cette fusion se joue dans le processus de développement. Jakub Kicinski a comptabilisé 632 correctifs net et 648 correctifs net-next. Selon son estimation, environ un tiers à la moitié de net-next était constitué de corrections, nettoyages ou clarifications de faible priorité produits avec l’aide de l’IA, soit approximativement 216 à 324 correctifs. Avec Paolo Abeni, il a décrit la charge de travail comme étant « complètement débordée ».

La réponse envisagée ne consiste pas à confier le noyau à un modèle unique. Meta a fourni un budget et un accès à plusieurs modèles d’IA de pointe afin que les correctifs puissent faire l’objet de plusieurs premières lectures. L’idée est de réduire le risque qu’une hallucination ou une mauvaise interprétation d’un modèle unique franchisse le processus sans être repérée.

Les tâches susceptibles d’être automatisées sont relativement structurées : gestion de Patchwork, retours procéduraux courants, amélioration des messages de commit et, éventuellement, application de correctifs déjà examinés par des personnes de confiance.

La limite reste essentielle dans le développement du noyau Linux. Les conditions de course rares et les chemins de récupération liés au matériel — par exemple les erreurs PCIe ou la gestion des délais d’expiration — demandent toujours une analyse humaine. L’IA peut absorber une partie du tri répétitif, mais elle ne remplace pas la compréhension de la concurrence, des contrats d’API et de l’ordre exact des opérations de récupération.

De nouveaux pilotes et plusieurs évolutions de protocole

La fusion réseau apporte aussi plusieurs briques de prise en charge matérielle :

• le pilote Wi-Fi HaLow Morse Micro mm81x fait ses premiers pas et prend en charge les périphériques USB et SDIO ;
• NXPWIFI arrive comme nouveau pilote sans fil pour les appareils NXP, tandis que les travaux sur le fonctionnement multiliaison se poursuivent ;
• Intel reçoit l’ossature initiale du pilote iXD, destiné à la prise en charge des fonctions Control Plane PIC sur les IPU et FNIC E2100 et ultérieurs ;
• le réseau filaire bénéficie d’une première prise en charge de CXL pour les cartes AMD/Solarflare et de la possibilité de flasher le micrologiciel des matériels AMD Pensando.

D’autres changements sont moins spectaculaires, mais utiles dans des situations particulières. MPTCP peut désormais, en dernier recours, élaguer ses files de paquets arrivés dans le désordre lorsque la mémoire disponible devient extrêmement faible. Il s’agit d’un mécanisme de récupération, et non d’une garantie de débit supérieur en fonctionnement normal.

Le passage de descripteurs de fichiers avec AF_UNIX devient également plus facile à diagnostiquer. Avec SO_RIGHTS_NOTRUNC, le récepteur peut identifier le descripteur rejeté et récupérer son errno lorsqu’un module de sécurité Linux (LSM) bloque un descripteur précis dans un tableau SCM_RIGHTS, au lieu de perdre le reste du tableau dès le premier refus.

Quand Linux 7.3 sera-t-il disponible ?

La première release candidate de Linux 7.3 est attendue autour du 30 août 2026. La version stable est pour sa part projetée vers la fin octobre, si le cycle de développement suit son calendrier habituel.

Cette échéance ne signifie pas que la majorité des serveurs et des ordinateurs de bureau bénéficieront de ces fonctions dès octobre. Les distributions choisissent leurs versions de noyau, rétroportent certains changements, effectuent leurs propres tests et publient leurs mises à jour selon un calendrier distinct. Les distributions à publication continue peuvent proposer le noyau plus tôt, tandis que les distributions à versions fixes peuvent attendre sensiblement plus longtemps.

CachyOS, qui suit un modèle de publication continue, pourrait figurer parmi les premières distributions à l’adopter. Toutefois, les informations disponibles pour sa publication d’août montrent encore des images utilisant Linux 7.1 et ne confirment aucune date d’adoption de Linux 7.3.

Ce que cela change pour les administrateurs

Pour les équipes chargées des infrastructures, les deux évolutions les plus concrètes à surveiller sont le chemin BIG TCP des tunnels VXLAN et Geneve, ainsi que la réduction de la contention lors de la configuration de règles dans un grand nombre d’espaces de noms réseau. Elles devraient particulièrement intéresser les installations qui combinent réseaux superposés et trafic à haut débit, ou qui créent de nombreux espaces de noms simultanément.

Pour les développeurs du noyau, l’expérimentation autour de l’IA pourrait être tout aussi importante. La fusion dessine une répartition pragmatique des rôles : les modèles prennent en charge le tri répétitif et les retours de procédure, tandis que les mainteneurs restent responsables des cas atypiques où un correctif apparemment plausible peut provoquer un interblocage, perturber une récupération matérielle ou enfreindre une règle implicite de synchronisation.

Linux 7.3 s’annonce donc riche en évolutions réseau. Mais avant que les utilisateurs puissent compter dessus, il faudra encore passer par les releases candidates, les validations sur matériel et l’intégration propre à chaque distribution.