DPDK: pianificare correttamente l'elaborazione dei pacchetti nello spazio utente

Principio fondamentale del DPDK e corretta classificazione

DPDK è un framework per applicazioni che devono elaborare pacchetti di rete con il minor overhead possibile nello spazio utente. Anziché seguire il percorso tradizionale che passa attraverso lo stack di rete del kernel, i socket e le relative strutture dei pacchetti, un'applicazione può utilizzare direttamente determinate schede di rete per il proprio percorso dati. Ciò mira soprattutto a garantire elevate velocità di trasmissione dei pacchetti, basse latenze e un'elaborazione facilmente pianificabile in presenza di molti pacchetti di piccole dimensioni.

L'espressione „senza limiti del kernel“ è in questo caso riduttiva. Il kernel Linux rimane attivo per il sistema operativo, la gestione della memoria, i processi, la sicurezza e numerose attività amministrative. DPDK non sostituisce né i limiti della scheda di rete né quelli relativi a PCIe, alla larghezza di banda della memoria o alla CPU. Per le interfacce collegate, aggirando soprattutto il consueto percorso dei dati del kernel, trasferisce l’elaborazione dei pacchetti a un’applicazione specializzata.

Nel percorso di rete standard di Linux, i driver di rete, NAPI, la gestione dei pacchetti e il livello socket interagiscono tra loro. Questo percorso non è, in generale, basato esclusivamente sugli interrupt. Un DPDK-Modalità sondaggio Driver interroga le code di ricezione direttamente dallo spazio utente. L'applicazione riceve i pacchetti in gruppi, li verifica o li modifica e successivamente li trasferisce a una coda di invio o a un'ulteriore fase di elaborazione.

Non si tratta di un’ottimizzazione generale del kernel e, per una normale applicazione web con poche connessioni TCP, di solito non è la prima misura da adottare. Solo quando il percorso dei pacchetti risulta essere palesemente limitato, ad esempio in caso di bilanciamento del carico a livello L4, filtraggio o endpoint di tunnel, il potenziale vantaggio giustifica l'ulteriore sforzo operativo. Le caratteristiche dipendenti dalla versione devono essere verificate rispetto alla documentazione del tag di release effettivamente utilizzato; una release candidate non è da equiparare a una release utilizzata in produzione.

Come funziona il percorso dei pacchetti nello spazio utente

All'ingresso, l'applicazione configura una o più code Rx della scheda di rete. Un core di esecuzione assegnato interroga una coda in un ciclo e riceve una raffica di pacchetti disponibili. Questi Elaborazione a raffica riduce il numero di chiamate alle funzioni e il carico amministrativo per ogni pacchetto. Dopo la classificazione, l'inoltro o la modifica, l'applicazione inserisce i pacchetti in blocco in una coda di trasmissione (Tx-Queue).

Il polling evita numerosi cambi di interrupt nel percorso dati sottoposto a carico elevato e rende più prevedibile il lavoro di un core. Il prezzo da pagare è una CPU costantemente attiva: anche quando la coda è vuota, l'lcore continua a verificare la presenza di nuovi pacchetti. Per questo motivo, questo modello è più adatto a carichi costantemente elevati che a interfacce con traffico sporadico o fortemente variabile.

I dati del pacchetto e i metadati si trovano in rte_mbuf-oggetti. Questi provengono da un mempool creato in precedenza e contengono, ad esempio, la lunghezza del pacchetto, la porta di ingresso, le informazioni di offload e, se del caso, un hash RSS. I pool riservati in anticipo, un’assegnazione fissa tra coda e nucleo e percorsi di elaborazione brevi favoriscono Località della cache ed evitiamo strutture di dati comuni non necessarie.

Tuttavia, Zero Copy non è una caratteristica automatica di DPDK. Se e dove i dati vengono copiati dipende dalla scheda di rete (NIC), dal driver, dagli offload e dalla logica dell'applicazione. I frame di grandi dimensioni o segmentati possono essere costituiti da più mbuf collegati tra loro; ciò è rilevante, ad esempio, nel caso dei jumbo frame. Chi rielabora, unisce o trasferisce dati di pacchetti tra buffer incompatibili deve tenere conto di eventuali spostamenti di memoria nel proprio percorso dati.

Architettura, risorse e limiti rigidi

Gli Environment Abstraction Layer, in breve EAL, inizializza DPDK e fornisce, tra le altre cose, la prenotazione di memoria, l’accesso alle periferiche, i timer e l’assegnazione dei nuclei logici. Su questa base, l’applicazione configura le code Ethernet, i mempool e la loro elaborazione. Un «lcore» è un core logico pianificato per DPDK, non semplicemente un thread dell’applicazione che si sposta a caso. Queste caratteristiche fondamentali di EAL sono documentate qui nella documentazione di DPDK 25.07; i dettagli specifici della versione devono essere verificati separatamente per il tag di rilascio utilizzato.

Per garantire un percorso lineare dei dati, spesso un kernel elabora un pacchetto per intero: dalla ricezione alla decisione fino all’invio. Questo modello “run-to-completion” evita i passaggi tra i kernel. Una pipeline, invece, suddivide in fasi, ad esempio, l’analisi sintattica, la ricerca del flusso e l’inoltro. È in grado di organizzare le responsabilità, ma introduce anelli, sincronizzazione e una località di memoria potenzialmente peggiore tra le fasi.

La progettazione deve tenere conto anche del modello NUMA. Queue, lcore e pool di pacchetti dovrebbero, se possibile, trovarsi sullo stesso nodo NUMA, in modo che il percorso dei dati non debba accedere regolarmente alla memoria di un altro socket della CPU. Le prestazioni ottenibili dipendono inoltre dalle funzionalità della scheda di rete (NIC), dalla connessione PCIe, dalla larghezza di banda della memoria, dalla frequenza di clock della CPU, dalla dimensione dei pacchetti e dalla complessità di ogni decisione relativa ai pacchetti.

Un bilanciatore di carico L4 è in grado di analizzare rapidamente le informazioni IP e di porta fornite da DPDK, assegnare i flussi e inoltrare i pacchetti. Tuttavia, ciò non rende automaticamente più veloci la terminazione TLS, gli stati NAT complessi, la registrazione dei log, gli health check o i backend lenti. Allo stesso modo, il piano di controllo necessita di tempo CPU disponibile per la configurazione, la telemetria e la gestione degli errori. DPDK accelera quindi un percorso dati ben definito, ma non necessariamente l’intero servizio.

Anche le dimensioni e la durata dei buffer dei pacchetti fanno parte dell’architettura. I mempool limitano il numero di buffer disponibili contemporaneamente, mentre l’applicazione deve gestire correttamente i passaggi di proprietà. I pool di dimensioni troppo ridotte possono esaurirsi sotto carico; le riserve eccessive occupano memoria inutilmente. La dimensione ottimale deriva dalle code, dalle dimensioni dei burst, dal percorso dei pacchetti e dai picchi di carico previsti, non da un valore predefinito universale.

Verificare i requisiti prima dell'utilizzo del DPDK

Il DPDK diventa pianificabile solo quando l'hardware, la memoria e l'assegnazione della CPU sono compatibili tra loro. Una semplice installazione non basta a garantire un percorso dati efficiente: il PMD deve supportare il modello specifico di scheda di rete (NIC) e le risorse devono poter essere riservate all’applicazione. La verifica che segue distingue i requisiti tecnici minimi dalle ipotesi che valgono solo per il dispositivo effettivamente utilizzato.

Le Hugepages sono la soluzione più comune per pool di pacchetti di grandi dimensioni, ma non rappresentano un requisito imprescindibile per ogni applicazione DPDK. L’EAL supporta anche l’opzione –no-huge. Questa modalità speciale non costituisce una raccomandazione standard equivalente: prima di avviare la fase pilota è necessario verificare l’idoneità, la gestione della memoria e i limiti dei driver. I fondamenti di sistema e dell’EAL qui utilizzati sono documentati in DPDK 25.07; verifica inoltre che le opzioni corrispondano alla versione effettivamente installata.

Particolarmente critica è la Associazione dei dispositivi. Molti PMD richiedono che la scheda di rete in questione venga scollegata dal driver standard del kernel e, ad esempio, collegata a vfio-pci viene associata. L'interfaccia non è quindi più disponibile normalmente per lo stack di rete standard di Linux. La procedura concreta deve tuttavia essere adeguata al PMD e non può essere applicata in modo generico a tutte le schede di rete supportate.

Un'importante eccezione è rappresentata dai PMD biforcati. La documentazione del driver sottolinea che tali PMD non devono essere scollegati dal relativo driver del kernel. In questo caso, il driver del kernel può rimanere collegato mentre un percorso dati dello spazio utente utilizza determinate risorse. La documentazione collegata, priva di versione, riflette lo stato di sviluppo 26.11.0-rc1 e non costituisce una guida specifica per la versione 26.07. Verifica il supporto dei dispositivi e gli strumenti del kernel disponibili nel manuale del PMD concretamente utilizzato.

Prima di ogni modifica, la seguente query di stato fornisce un riepilogo dei dispositivi PCI e delle relative associazioni di driver attuali. La query non modifica alcuna associazione. Eseguirla sul sistema di destinazione utilizzando il percorso corrispondente alla struttura sorgente o degli strumenti DPDK installata.

./usertools/dpdk-devbind.py --status

L'accesso alla gestione del piano e il percorso dei dati di produzione devono essere separati, anche se il PMD selezionato non sostituisce il driver del kernel. L'accessibilità tramite SSH o console non deve dipendere da un'interfaccia il cui collegamento o la cui ripartizione del traffico venga modificata durante la fase pilota. Un’interfaccia di gestione separata, un accesso fuori banda o un percorso di ripristino locale preventivamente verificato limitano il rischio di una configurazione errata.

Confronto tra DPDK, AF_XDP e Kernelstack

La scelta del percorso dei dati non è una classifica, bensì una decisione operativa. Lo stack del kernel Linux, AF_XDP e DPDK comportano ciascuno un diverso carico di lavoro, accesso alle periferiche e consumo di CPU. L'opzione più adatta dipende dal fatto che siano effettivamente la velocità di trasmissione dei pacchetti o la latenza nel percorso di rete a costituire il limite, oppure se siano l'applicazione, la crittografia e i backend a rappresentare il collo di bottiglia.

AF_XDP è un'opzione intermedia per i team che desiderano elaborare i pacchetti in anticipo pur rimanendo vicini al modello di rete Linux. Il kernel descrive una modalità di copia e la modalità Zero Copy, che richiede il supporto del driver. Se viene espressamente richiesta la modalità Zero Copy, la creazione del socket potrebbe fallire qualora il driver non offra tale funzionalità. Per comprendere meglio il livello XDP, è utile consultare l'articolo XDP ed eXpress Data Path.

DPDK, invece, utilizza driver in modalità poll ed elabora le code direttamente dall'applicazione. Ciò consente di aggirare le parti relative ai socket e agli interrupt nel percorso dei dati di DPDK, ma richiede la gestione della memoria, delle code e dell'allocazione dei core. Zero Copy Non si tratta né di una promessa generale di prestazioni né di una caratteristica automatica di un qualsiasi percorso DPDK; il numero di copie dipende dall'applicazione, dagli offload e dai trasferimenti di memoria.

Scegli lo stack del kernel se il routing, il firewall, l’osservabilità e la semplicità operativa sono più importanti di un percorso dei pacchetti specializzato. Valuta l'utilizzo di AF_XDP in caso di accelerazione mirata con integrazione nel kernel. DPDK è vantaggioso solo in presenza di un'effettiva necessità di un'elevata velocità di trasmissione dei pacchetti o di una latenza costante, di un supporto NIC esistente e di un team in grado di assumersi in modo permanente la responsabilità operativa aggiuntiva.

Pianificare in modo oculato le code, il CPU-pinning e il NUMA

Una resistente Assegnazione delle code Si parte dalla vicinanza tra NIC, CPU e memoria. L’EAL supporta la selezione dei nuclei logici, la prenotazione della memoria e l’allocazione dei dispositivi. Per un percorso dati semplice, è solitamente opportuno assegnare in modo fisso una coda Rx a un lcore, creare il mempool associato sul nodo NUMA locale e quindi trasferire l’elaborazione a una coda Tx adeguata. Queste informazioni di base sull’EAL sono documentate nella documentazione di DPDK 25.07 e, per le opzioni dipendenti dalla versione, devono essere verificate in base al tag di rilascio utilizzato.

Un esempio non specifico di prodotto per un host con due nodi NUMA potrebbe essere il seguente: la scheda di rete (NIC) sul nodo 0 riceve due code di ricezione (Rx); un lcore per ciascun nodo 0 elabora una coda per intero. Anche i buffer dei pacchetti si trovano sul nodo 0. Un altro core, che non esegue operazioni di polling, rimane libero per le attività di gestione, mentre il nodo 1 è destinato ad altri servizi o a percorsi dati chiaramente separati.

• Percorso dei dati: per ogni coda, un lcore assegnato in modo fisso, pool di memoria locali e coppie Rx/Tx chiaramente identificate.
• Amministrazione: mantenere libera la capacità della CPU per la telemetria, la logica di controllo, gli eventi e i servizi del sistema operativo.
• Riserva: prevedere una capacità per i picchi di carico, la risoluzione dei problemi e gli ampliamenti pianificati, anziché allocare tutti i core in modo permanente.

Non condividere una coda Rx tra più lcore. La guida PMD sconsiglia di condividere le code Rx e Tx, poiché i blocchi globali necessari a tal fine possono compromettere notevolmente le prestazioni. L'accesso simultaneo di più lcore a una coda Tx è previsto come eccezione documentata solo se il driver supporta la funzionalità RTE_ETH_TX_OFFLOAD_MT_LOCKFREE segnala. Verifica questa funzionalità per la specifica combinazione NIC/PMD; non dedurla né dalla velocità della porta né da un interruttore di offload generico.

Una pipeline con fasi separate di analisi, classificazione e invio può rendere più chiare le responsabilità. L’approccio documentato basato sulla pipeline trasferisce i pacchetti ad altri nuclei tramite anelli; ciò comporta ulteriori accessi alla memoria e passaggi di dati. Per filtri semplici o l'inoltro L4, l’esecuzione fino al completamento per ogni coda è spesso più facile da pianificare. Si dovrebbero utilizzare più fasi solo se la suddivisione del lavoro giustifica il carico aggiuntivo nel profilo di carico specifico.

Anche Offload hardware non devono essere prese in considerazione nella progettazione. Le funzioni di checksum, segmentazione, RSS o flusso disponibili dipendono dalle capacità del dispositivo Ethernet specifico e del suo PMD. Verificale prima della progettazione e considera l’assenza di un’operazione di offload come un caso normale di progettazione, non come un’eccezione.

Monitoraggio sicuro del funzionamento del DPDK

Il funzionamento di un percorso dati DPDK richiede metriche che prendano in considerazione sia l'elaborazione dei pacchetti che le risorse. È necessario registrare almeno i pacchetti elaborati, scartati e difettosi, nonché i valori specifici dell'applicazione relativi alle velocità di elaborazione, alle riserve del mempool e Distribuzione della latenza anziché un unico valore medio. La disponibilità di ulteriori contatori di porte, code o driver dipende dal PMD specifico, dalla scheda di rete (NIC) e dall'applicazione, e deve essere verificata per la combinazione utilizzata.

Il polling rappresenta un conflitto di obiettivi intenzionale. Un lcore interroga continuamente la propria coda Rx affinché i pacchetti possano essere elaborati senza ricorrere al normale percorso di interrupt. Anche in presenza di traffico scarso o assente, il ciclo di polling rimane comunque attivo. Si raccomanda pertanto di prevedere, oltre agli lcore del percorso dati, una capacità della CPU dedicata alla logica di controllo, alla telemetria e al sistema operativo. La documentazione EAL utilizzata a titolo integrativo si riferisce a DPDK 25.07; le funzionalità dipendenti dalla versione devono essere verificate in base alla versione installata.

Per l’analisi delle cause è importante la correlazione temporale. Se la perdita di pacchetti si verifica contemporaneamente alla presenza di contatori di errori, alla diminuzione delle riserve del mempool o a un percorso dati lcore saturo, si tratta inizialmente di indizi verificabili e non ancora di una prova univoca della causa. I tempi di risposta variabili possono essere correlati, tra l’altro, alla memoria lontana dal NUMA, a attività concorrenti o a passaggi di pipeline. Confronta tali ipotesi con l’assegnazione dei core, la distribuzione delle code e i valori misurati nella stessa finestra temporale.

Una raccolta rapida dei dati a livello di interfaccia non equivale a una registrazione completa e senza perdite dei pacchetti nel lungo periodo. Per le statistiche di flusso o l’analisi delle intestazioni possono essere sufficienti pochi metadati. Se si desidera salvare ogni pacchetto, la struttura del sistema è ulteriormente limitata dalla larghezza di banda di memoria, dal volume del buffer, dalla velocità di scrittura e dal supporto di memorizzazione scelto. La protezione dei dati e le norme di conservazione sono requisiti indipendenti che la velocità di trasmissione della rete non risolve.

Pianifica le macchine virtuali e i container come attività di integrazione a sé stante. Verifica, per la piattaforma specifica, in che modo vengono forniti l’accesso alle periferiche, la memoria, l’assegnazione della CPU e i diritti necessari. Verifica questa combinazione con il PMD in uso, anziché applicare in modo generico i parametri di esempio. La guida Linux collegata si riferisce attualmente alla versione di sviluppo 26.11.0-rc1; per una configurazione in produzione fa fede la documentazione della versione effettivamente installata.

Verificare sistematicamente i casi tipici di guasto

La ricerca dei guasti dovrebbe innanzitutto distinguere i sintomi osservabili dalle possibili cause. Non modificare contemporaneamente l’associazione del driver, il numero della coda e i parametri di memoria, poiché in tal caso non sarebbe più possibile individuare la causa scatenante. I contatori non distruttivi, le informazioni sulla configurazione e un confronto tra la coda interessata e quella non interessata forniscono solitamente indicazioni più attendibili prima di intervenire.

In caso di comportamento anomalo della coda, controlla il proprietario della coda e il nodo NUMA del mempool. Nel modello «run-to-completion», l'lcore assegnato gestisce la ricezione, l'elaborazione e l'invio; una pipeline trasferisce i pacchetti ad altri core. Non suddividere comunque la coda Rx tra gli lcore. L'accesso simultaneo a una coda Tx è consentito solo se segnalato RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Questa funzionalità è prevista come eccezione. Un blocco impostato autonomamente non rende la condivisione della coda una strategia di scalabilità consigliata.

In assenza di offload hardware, la domanda giusta da porsi non è solo quale opzione sia stata selezionata, ma quali funzionalità siano effettivamente fornite dal dispositivo e dal PMD. Un'applicazione può pianificare una funzione desiderata senza che questa sia disponibile per quel modello. Confronta il supporto per la scheda di rete specifica con le funzionalità segnalate in fase di esecuzione prima di rendere il percorso dei dati dipendente da tale offload.

I risultati di testpmd devono essere considerati come riferimento o verifica funzionale, non come prova delle prestazioni dell’applicazione finale. Nella modalità io-forwarding, i pacchetti vengono inoltrati senza modifiche, senza che il loro contenuto venga analizzato ai fini dell’elaborazione tecnica. Questa modalità non gestisce parser, tabelle di flusso, NAT, crittografia e stato del protocollo. La documentazione collegata, non versionata, si riferisce alla versione 26.11.0-rc1; verifica il comportamento nel manuale della versione installata. Prendi nota della modalità di inoltro, della dimensione dei pacchetti, del numero di code Rx/Tx e dei core di inoltro e ripeti il confronto con la logica di elaborazione reale.

Implementazione, gestione delle versioni e decisione sull'utilizzo

Inizia con un test isolato e un profilo di carico: dimensioni dei pacchetti, carico di picco, numero di flussi e fasi di elaborazione necessarie. Verifica la scheda NIC specifica, compreso il driver Poll Mode corrispondente e le funzioni necessarie, consultando la panoramica ufficiale dell’hardware e la matrice dei driver. La semplice presenza di un produttore nell’elenco non garantisce né la compatibilità con ogni scheda né il supporto di tutti gli offload. Esegui quindi dei test con una logica applicativa reale, non limitandoti esclusivamente a un esempio di inoltro.

Annota la versione DPDK, il firmware, i driver, il kernel e la configurazione per ogni prova. Prima di effettuare un aggiornamento, leggi le note di rilascio relative al tag di rilascio specificatamente previsto e documenta quali modifiche sono rilevanti per il proprio percorso dati. Le note di rilascio di versioni diverse non sostituiscono questa corrispondenza, poiché le funzionalità e le limitazioni possono variare da una versione all'altra.

Un punto specifico da verificare, riportato nelle note di rilascio di DPDK 26.07, è l’algoritmo modificato di flush/refill della cache del mempool: da allora la sua dimensione effettiva corrisponde a quella configurata; in precedenza era superiore del 50%. Solo nel caso in cui ogni lcore prelevi o restituisca esclusivamente oggetti da un mempool, le note di rilascio raccomandano di raddoppiare la dimensione configurata della cache, al fine di evitare un possibile raddoppio del tasso di cache miss. Ciò riguarda, ad esempio, le pipeline con lcore Rx e Tx separati, non in generale il «run-to-completion». La modifica riguarda la versione 26.07; la pagina storica della versione collegata si trova ora all’interno della documentazione relativa alla versione 26.11.0-rc1.

Inizia con un progetto pilota di portata limitata e criteri di interruzione ben definiti. Confronta la velocità di trasmissione, i percentili di latenza elevati, la perdita di pacchetti e il fabbisogno di CPU a parità di condizioni rispetto al funzionamento precedente. Verifica il monitoraggio, i riavvii e il ripristino della configurazione precedente. Tieni conto dei costi operativi; da questi non è possibile dedurre una garanzia generale di throughput.

La scelta di utilizzare DPDK è particolarmente vantaggiosa quando i benefici misurati giustificano il carico di manutenzione aggiuntivo. Per quanto riguarda l'integrazione nella piattaforma di sistema circostante, l'articolo fornisce ulteriori informazioni Il kernel Linux nell'ambito dell'hosting La pianificazione. Per i normali servizi di hosting, mantieni anche il percorso di rete esistente come base di confronto nel test.