Linux 7.3 accelera le reti overlay e sperimenta l’IA nella revisione delle patch

Il merge del networking di Linux 7.3 si distingue per due motivi molto diversi: da un lato punta a migliorare le prestazioni dei carichi di lavoro basati su overlay e su molti namespace; dall’altro mostra come i maintainer stiano cercando di gestire il crescente volume di patch generate o assistite dall’intelligenza artificiale. Il codice è entrato nel ramo principale durante il merge window del 20 agosto 2026, ma Linux 7.3 non è ancora un kernel stabile rilasciato.

Le novità più importanti per il networking

BIG TCP arriva nei tunnel VXLAN e Geneve

Linux 7.3 estende il supporto a BIG TCP ai driver per tunnel UDP VXLAN e Geneve. Il kernel può così gestire internamente payload superiori a 64 KiB e suddividerli tramite GSO e TSO prima che arrivino sul cavo. L’obiettivo è ridurre il lavoro per-pacchetto nei percorsi di rete basati su overlay, non trasmettere pacchetti fuori misura sulla rete fisica.

I risultati riportati con

netperf TCP_STREAM

• con MTU standard, il throughput VXLAN è passato da 34,44 a 39,56 Gbit/s, pari a un aumento del 14,9%;
• con l’offload hardware del tunnel disattivato, VXLAN è salito da 21,82 a 29,39 Gbit/s, cioè del 34,7%;
• Geneve è passato da 37,39 a 40,89 Gbit/s, con un incremento del 9,4% a MTU standard.

Si tratta di misurazioni legate a una configurazione specifica. Il risultato effettivo dipende dall’intero percorso end-to-end: valori come gso_max_size e gro_max_size, capacità della scheda di rete, stato degli offload, MTU, tipo di tunnel e carico di lavoro. Prima di aspettarsi gli stessi incrementi, chi gestisce infrastrutture VXLAN o Geneve dovrebbe quindi eseguire benchmark sul proprio ambiente.

Meno serializzazione RTNL per l’aggiornamento delle regole di routing

Il merge riduce inoltre la dipendenza dal grande lock globale RTNL durante l’inserimento e la rimozione delle regole FIB IPv4 e IPv6. Quando possibile, le operazioni usano ora mutex associati alla struttura fib_rules_ops pertinente, permettendo una maggiore esecuzione parallela. RTNL resta comunque necessario in alcuni percorsi, incluso fib_unmerge() della prima regola IPv4.

Un test sintetico mostra il vantaggio possibile negli scenari di gestione intensiva dei namespace. La creazione parallela di 4.096 network namespace, con l’aggiunta di 1.024 regole a ciascuno, è passata da 22,752 a 0,918 secondi per IPv4, circa 24,8 volte più veloce, e da 35,181 a 1,214 secondi per IPv6, circa 29,0 volte più veloce. Sono numeri che fotografano una contesa estrema sui lock, non un miglioramento garantito nell’avvio dei normali container o in qualsiasi carico di routing.

Perché i maintainer stanno ricorrendo all’IA per il triage delle patch

Il sottosistema networking sta diventando anche un banco di prova per lo sviluppo del kernel assistito dall’IA. Jakub Kicinski ha riferito di 632 patch net e 648 patch net-next, stimando che tra un terzo e metà di net-next fosse composto da correzioni, pulizie o chiarimenti a bassa priorità guidati dall’IA. La stima equivale a circa 216-324 patch. Kicinski e Paolo Abeni hanno descritto il carico di lavoro come “completely overwhelmed”, cioè completamente ingestibile.

La risposta proposta non consiste nel sostituire i maintainer con un singolo modello. Meta ha messo a disposizione budget e accesso a più modelli di IA di frontiera, così che ogni patch possa ricevere diverse revisioni preliminari. L’idea è ridurre il rischio che un’allucinazione o un’interpretazione errata di un singolo modello superi il processo senza essere individuata.

L’automazione prevista comprende la gestione di Patchwork, i commenti procedurali di routine, la modifica dei messaggi di commit e, potenzialmente, l’applicazione di patch già esaminate da persone di fiducia. Si tratta di attività più strutturate rispetto alla valutazione della correttezza di una modifica che interviene in un raro percorso di errore.

La distinzione è fondamentale nel networking del kernel. I maintainer hanno sottolineato che condizioni di gara insolite e percorsi di recupero dell’hardware, come la gestione degli errori PCIe e dei timeout, richiedono ancora un controllo umano. L’IA può filtrare il lavoro ripetitivo, ma non elimina la necessità di comprendere concorrenza, contratti delle API e sequenza delle operazioni di recupero.

Nuovi driver e miglioramenti ai protocolli

Il pull del networking include diversi interventi di abilitazione hardware e protocollare:

• arriva il primo driver Morse Micro mm81x per il Wi-Fi HaLow, con supporto ai dispositivi USB e SDIO;
• NXPWIFI debutta come nuovo driver wireless per NXP, mentre prosegue il lavoro sul funzionamento multi-link;
• Intel riceve lo scheletro iniziale del driver iXD per il supporto Control Plane PIC Function sulle IPU E2100 e successive e sulle FNIC;
• sul networking cablato arrivano il supporto iniziale a CXL per le schede AMD/Solarflare e il supporto al flashing del firmware per l’hardware AMD Pensando.

Non mancano interventi più piccoli, ma utili. MPTCP introduce un meccanismo di emergenza per eliminare le code dei pacchetti fuori ordine in condizioni di pressione estrema sulla memoria. È una misura di recupero per situazioni degradate, non una promessa di maggiore throughput nell’uso quotidiano.

Anche il passaggio di file descriptor tramite AF_UNIX diventa più semplice da diagnosticare. Con SO_RIGHTS_NOTRUNC, quando un LSM blocca uno specifico descrittore all’interno di un array SCM_RIGHTS, il destinatario può identificare il descrittore rifiutato e il relativo errno, invece di perdere il resto dell’array al primo rifiuto.

Quando arriverà Linux 7.3 agli utenti?

La prima release candidate di Linux 7.3 era prevista intorno al 30 agosto 2026, mentre la versione stabile era stimata per la fine di ottobre, se il ciclo di sviluppo avesse seguito il calendario abituale.

Questo non significa che la maggior parte dei server e dei desktop riceverà queste funzioni di rete già a ottobre. I maintainer delle distribuzioni scelgono le versioni del kernel, effettuano il backport di alcune modifiche, conducono i propri test e pubblicano gli aggiornamenti secondo tempistiche indipendenti. Le distribuzioni rolling possono impacchettare il kernel prima; quelle a rilascio fisso possono richiedere molto più tempo.

CachyOS è un possibile candidato all’adozione anticipata perché segue un modello rolling, ma le informazioni disponibili sull’edizione di agosto mostrano immagini basate su Linux 7.1 e non confermano una data di adozione di Linux 7.3.

Cosa cambia davvero per chi gestisce infrastrutture

Per i team IT, gli interventi da seguire più da vicino sono il percorso BIG TCP per gli overlay e la riduzione della contesa durante la gestione su larga scala delle regole dei network namespace. Possono risultare particolarmente interessanti negli ambienti che combinano VXLAN o Geneve con traffico ad alto throughput, oppure che creano e configurano molti namespace contemporaneamente.

Per gli sviluppatori del kernel, l’esperimento sulla revisione con l’IA potrebbe avere conseguenze altrettanto rilevanti. Il merge suggerisce una divisione pratica dei compiti: i modelli possono assorbire il triage ripetitivo e i feedback procedurali, mentre ai maintainer resta la responsabilità dei casi insoliti, nei quali una patch apparentemente plausibile può causare un deadlock, gestire male un recupero o violare una regola di sincronizzazione implicita.

Il risultato è un insieme consistente di novità per il networking in arrivo con Linux 7.3. Prima che la maggior parte degli utenti possa farvi affidamento serviranno però i test delle release candidate, la validazione su hardware reale e l’integrazione da parte delle distribuzioni.