In Linux 7.4 l'offload del pacing dei pacchetti è noioso, ed è proprio questo il punto

Quale modifica di Linux 7.4 conterà di più tra due anni: quella che trasforma un passaggio dell'avvio da minuti a millisecondi, o un nuovo attributo dei dispositivi di rete che la maggior parte delle persone non vedrà mai? Noi puntiamo sulla seconda. È noiosa, ma di quella noia che di solito invecchia bene.

Cosa è arrivato, in due paragrafi

Come riporta Phoronix, il codice di rete centrale di Linux 7.4 guadagna l'offload hardware del pacing, con un nuovo attributo "pacing_offload" per i dispositivi di rete. L'idea è affidare alla NIC o alla SmartNIC il controllo della cadenza e della spaziatura dei pacchetti in uscita, un compito che finora svolgeva il kernel stesso. Il driver IDPF è il primo a implementarlo.

La serie di patch, che compare su LWN a firma di Willem de Bruijn di Google, la descrive come l'attivazione di un offload hardware del pacing "sicuro" su un primo dispositivo, con supporto rtnetlink perché gli amministratori possano controllare la funzione, più una piccola ottimizzazione dell'offload FQ. La finestra di merge della 7.4 è ancora aperta, e un resoconto indica come obiettivo un rilascio a fine dicembre.

I grandi miglioramenti sono il posto sbagliato dove guardare

Linux 7.4 ha parecchie novità che colpiscono. Un resoconto cita un'operazione di memoria all'avvio che scende da circa 268 secondi a 50 millisecondi. Un altro parla di un miglioramento di FAT32 fino a 265 volte. Fanno ottimi titoli, e non dubitiamo che siano reali. Ma correzioni isolate come queste funzionano eliminando un caso patologico. Se ne beneficia una volta, poi non c'è più nulla.

L'offload del pacing è di un'altra specie. Non ripara nulla di rotto. Sposta un compito ricorrente su hardware progettato per quello. Ogni pacchetto che lascia una macchina molto carica deve essere distanziato con criterio, e farlo via software costa tempo di CPU a ogni invio. Spostarlo sulla NIC rende in proporzione al traffico che movimenti, non alla sfortuna che hai.

Perché lo leggiamo come una storia di data center per l'IA

Prima una precisazione: nulla nel materiale che abbiamo visto dice che questo lavoro sia nato da carichi di IA. Quel collegamento è una nostra interpretazione. Ma torna. I grandi cluster spostano enormi volumi di dati tra le macchine, e in quell'ambiente i cicli di CPU spesi per la temporizzazione dei pacchetti sono cicli non spesi per qualcosa di utile. Delegare alla NIC è la direzione naturale.

È significativo anche che il primo driver supportato sia IDPF, relativo a una sola famiglia di dispositivi, e che la funzione sia esposta come un interruttore controllato dall'amministratore e non come una modifica globale. È un'ingegneria cauta e graduale. Pensiamo sia il modo giusto: dimostrarlo su un dispositivo, dare agli operatori un modo per attivarlo e lasciare che gli altri seguano.

L'altra faccia è un limite concreto. Come dice un titolo, è pacing dei pacchetti in hardware "se la tua NIC lo supporta". Per ora la maggior parte dei lettori non vedrà alcun cambiamento. Chi usa un portatile o un tipico server domestico oggi non ne ricava nulla. Gli offload hardware storicamente arrivano in modo disomogeneo, e dai driver degli altri produttori dipenderà se questo diventerà comune o resterà un'opzione di nicchia.

Chi vince e cosa fare

Vincono gli operatori di grandi reti con hardware compatibile e Linux stesso, che mantiene il suo ruolo di piattaforma predefinita per quel tipo di infrastruttura. Perdono, probabilmente, chi pensa ancora che il progresso del kernel si misuri in funzioni da titolo.

Il nostro consiglio è modesto. Se gestisci hardware basato su IDPF su larga scala, tieni d'occhio il rilascio della 7.4 e prova l'attributo prima di attivarlo dove conta davvero. Tutti gli altri possono archiviare la cosa tranquillamente sotto "cose che accadono sotto il pavimento". Aggiungeremmo solo che è sotto il pavimento che arriverà gran parte della performance del prossimo decennio.