Linux 7.3 porta BIG TCP nei tunnel overlay, ma il vero problema è il volume dei patch AI

Il possibile vantaggio non riguarda quindi soltanto reti con jumbo frame o schede dotate di offload hardware per i tunnel. Anche in configurazioni con MTU standard e senza supporto hardware dedicato, il kernel può gestire internamente un numero inferiore di pacchetti, ma di dimensioni maggiori.

La serie di patch alla base del lavoro ha dovuto rimuovere diverse assunzioni del codice: alcuni percorsi presumevano che la lunghezza dei pacchetti restasse sotto i 64 KiB oppure la memorizzavano in campi da 16 bit, troncandola. Il lavoro copre i carichi BIG TCP IPv4 e IPv6 per VXLAN e Geneve.

Meno contesa sul lock globale RTNL

Un’altra modifica riduce la dipendenza dal lock globale RTNL nelle operazioni sulle regole della FIB, tra cui RTM_NEWRULE e RTM_DELRULE. Il cambiamento è pensato soprattutto per i sistemi che gestiscono regole di routing in molti namespace di rete: eliminare un punto di serializzazione globale può lasciare maggiore spazio al parallelismo.

Le fonti disponibili confermano l’obiettivo architetturale, ma non forniscono benchmark affidabili con incrementi precisi per IPv4 o IPv6. Non è quindi possibile indicare percentuali o moltiplicatori di prestazioni senza andare oltre le prove disponibili.

Driver e aggiornamenti ai protocolli

Il pull del networking amplia anche il supporto a hardware e protocolli:

• il lavoro sul wireless include il driver Morse Micro mm81x, destinato a dispositivi S1G a lungo raggio, e un nuovo driver NXPWIFI;
• l’infrastruttura preliminare Intel iXD punta alla Control Plane PIC Function delle IPU e delle FNIC Intel E2100 e successive;
• MPTCP migliora il comportamento in condizioni di pressione estrema sulla memoria, anche tramite il ridimensionamento della coda di ricezione dei pacchetti fuori ordine;
• il pull comprende inoltre altri miglioramenti, correzioni e aggiornamenti per componenti di rete cablati e wireless.

Queste modifiche sono entrate nel lavoro del merge window di Linux 7.3. Non vanno confuse con una versione stabile già pubblicata: Linux 7.3 è ancora nel ciclo di sviluppo.

Perché i manutentori si sono definiti «completamente sopraffatti»

Kicinski e Abeni hanno riferito di aver unito 632 patch del ramo net e 648 del ramo net-next: 1.280 patch complessive nel pull del networking. Il conteggio, hanno avvertito, non rappresenta nemmeno tutto il carico di revisione. La loro stima «rapida e approssimativa» è che tra un terzo e metà delle patch di net-next sembri composto da correzioni, pulizie o chiarimenti a bassa priorità guidati dall’AI.

La pressione si inserisce in un aumento più ampio degli invii. In un periodo di soli nove giorni il sottosistema ha ricevuto 405 contributi con il tag

[PATCH net]

[PATCH net-next]

Il problema non è soltanto che l’AI sia in grado di scrivere codice. I contributori che usano modelli linguistici possono produrre a costi molto bassi anche spiegazioni plausibili, segnalazioni di bug e richieste di revisione. Spetta comunque ai manutentori umani stabilire se ogni modifica sia necessaria, corretta, sicura e meritevole di entrare nel kernel.

Come verrà usata l’AI nella revisione

I manutentori hanno dichiarato di aver ottenuto, con finanziamento Meta, accesso e budget sufficienti per impiegare più modelli linguistici di grandi dimensioni nella revisione delle patch. L’obiettivo immediato è intercettare alcune modifiche allucinate o deboli prima che consumino ulteriore tempo umano.

I modelli dovrebbero essere indirizzati anche verso attività ripetitive del flusso di lavoro, tra cui:

• gestione delle code di Patchwork;
• feedback sui problemi ricorrenti nel processo di invio;
• modifica dei messaggi di commit;
• possibile applicazione di patch che abbiano già ricevuto tag di revisione da persone fidate.

L’impostazione considera quindi gli LLM come assistenti del flusso di lavoro, non come sostituti dei manutentori del sottosistema. La distinzione è particolarmente importante nel codice del kernel sensibile alla concorrenza. Kicinski e Abeni hanno richiamato l’attenzione su percorsi rari, come gli errori PCIe e i timeout, nei quali le race condition dipendenti dalla temporizzazione possono essere difficili da esporre — o da dimostrare assenti. Una revisione automatizzata può aiutare a individuare schemi sospetti, ma non può stabilire in modo affidabile la correttezza di ogni possibile interleaving.

Cosa non è ancora noto

Le informazioni disponibili non indicano le date previste per Linux 7.3-rc1 né per la versione stabile finale. Descrivono modifiche al networking entrate nel ciclo di sviluppo di Linux 7.3, non un calendario ufficiale di rilascio.

Allo stesso modo, le modifiche a RTNL puntano a migliorare il parallelismo delle operazioni sulle regole FIB tra namespace di rete, ma il materiale disponibile non consente di quantificare con precisione il guadagno in IPv4 o IPv6. La conclusione più solida è architetturale: meno contesa sul lock globale dovrebbe aiutare i carichi altamente paralleli di gestione dei namespace, mentre l’entità del beneficio dipenderà dal carico e dalla configurazione del sistema.