Ces chiffres ne constituent pas une promesse de gain universel pour Linux 7.3. Les résultats dépendent notamment de gso_max_size et gro_max_size, des capacités de la carte réseau, de l’état des offloads, de la MTU, du type de tunnel et de la charge de travail.
Le merge réduit également la dépendance au verrou global RTNL, longtemps utilisé pour sérialiser de nombreuses opérations de configuration réseau. L’ajout et la suppression des règles FIB IPv4 et IPv6 — RTM_NEWRULE et RTM_DELRULE — s’appuient désormais, lorsque c’est possible, sur un mutex propre à chaque fib_rules_ops.
RTNL n’a toutefois pas disparu du chemin. Il reste nécessaire dans certains cas, notamment lors du parcours fib_unmerge() associé à la première règle IPv4.
L’intérêt apparaît surtout dans les environnements qui manipulent simultanément de nombreux espaces de noms réseau. Dans un test synthétique créant 4 096 espaces de noms et insérant 1 024 règles dans chacun en parallèle, le temps de traitement IPv4 est passé de 22,752 à 0,918 seconde, soit un facteur d’environ 24,8. En IPv6, il est passé de 35,181 à 1,214 seconde, soit environ 29 fois plus rapide.
Il s’agit d’un scénario de contention particulièrement intense, et non d’une mesure représentative du temps de démarrage habituel d’un conteneur.
Jakub Kicinski a comptabilisé 632 correctifs net et 648 correctifs net-next. Selon son estimation, entre un tiers et la moitié de net-next seraient constitués de correctifs, nettoyages ou clarifications de faible priorité produits avec l’aide de l’IA — soit environ 216 à 324 patchs. Avec Paolo Abeni, il s’est décrit comme « complètement submergé ».
Meta a fourni un budget et un accès à plusieurs modèles de pointe afin que chaque patch puisse faire l’objet d’une première revue par plusieurs systèmes. L’objectif est notamment de limiter les hallucinations propres à un modèle unique.
L’automatisation envisagée pourrait couvrir :
Les mainteneurs ne considèrent toutefois pas cette approche comme suffisante pour les chemins rares et sensibles aux conditions de concurrence. Les erreurs PCIe, les délais d’attente et les séquences de récupération du matériel restent des domaines où il faut vérifier finement le comportement des API et l’ordre des opérations.
Le cycle Linux 7.3 apporte également plusieurs évolutions côté matériel et protocoles :
SCM_RIGHTS : avec SO_RIGHTS_NOTRUNC, le processus receveur peut mieux identifier le descripteur rejeté par un LSM et l’erreur associée, au lieu de perdre le reste du tableau dès le premier refus. Le premier candidat à la publication, ou release candidate, était attendu autour du 30 août 2026. La version stable restait alors envisagée pour la fin octobre, sous réserve du déroulement habituel du cycle de développement.
Les utilisateurs de distributions à versions fixes devront probablement patienter davantage : les éditeurs sélectionnent, rétroportent, testent et publient les noyaux selon leur propre calendrier. Les distributions en publication continue pourront proposer Linux 7.3 plus tôt.