DPDK: Pakketverwerking in de gebruikersruimte goed plannen

Het basisprincipe van DPDK en de juiste indeling

DPDK is een framework voor toepassingen die netwerkpakketten met zo min mogelijk overhead in de gebruikersruimte moeten verwerken. In plaats van de gebruikelijke route via de kernel-netwerkstack, sockets en de bijbehorende pakketstructuren te volgen, kan een toepassing geselecteerde netwerkkaarten rechtstreeks gebruiken voor haar eigen gegevenspad. Dit is vooral gericht op hoge pakketsnelheden, lage latenties en goed planbare verwerking bij grote aantallen kleine pakketten.

De formulering „zonder kernelbeperkingen“ is hierbij een vereenvoudiging. De Linux-kernel blijft aanwezig voor het besturingssysteem, het geheugenbeheer, processen, beveiliging en talrijke beheertaken. DPDK vervangt ook geen beperkingen van de netwerkkaart, noch PCIe-, geheugenbandbreedte- of CPU-beperkingen. Het omzeilt voor gekoppelde interfaces vooral het gebruikelijke kernel-gegevenspad en verplaatst de pakketverwerking naar een gespecialiseerde toepassing.

In het standaard Linux-netwerkpad werken netwerkstuurprogramma's, NAPI, pakketbeheer en de socketlaag samen. Dit pad is niet in alle gevallen uitsluitend op interrupts gebaseerd. Een DPDK-Poll-modus Driver haalt ontvangstwachtrijen rechtstreeks uit de gebruikersruimte op. De toepassing ontvangt pakketten in groepen, controleert of wijzigt ze en geeft ze vervolgens door aan een verzendwachtrij of een volgende verwerkingsfase.

Dit is geen algemene kernel-tuning en voor een gewone webtoepassing met weinig TCP-verbindingen meestal niet de eerste maatregel. Pas wanneer het pakketgegevenspad zelf aantoonbaar beperkend werkt, bijvoorbeeld bij L4-loadbalancing, filtering of tunnel-eindpunten, rechtvaardigt de mogelijke winst de extra operationele inspanning. Versieafhankelijke eigenschappen moeten worden getoetst aan de documentatie van de daadwerkelijk gebruikte releasetag; een release candidate is daarbij niet gelijk te stellen aan een release die in productie wordt gebruikt.

Hoe het pakketpad in de gebruikersruimte werkt

Bij de ingang configureert de toepassing een of meer Rx-wachtrijen van de netwerkkaart. Een toegewezen uitvoeringskern doorzoekt een wachtrij in een lus en ontvangt een reeks beschikbare pakketten. Deze Burst-verwerking vermindert het aantal functieaanroepen en de administratieve rompslomp per pakket. Na classificatie, doorsturing of wijziging plaatst de applicatie de pakketten gebundeld in een Tx-wachtrij.

Polling voorkomt veel interruptwisselingen in het zwaar belaste datapad en maakt de werking van een kern beter voorspelbaar. De keerzijde hiervan is dat de CPU continu actief blijft: zelfs als de wachtrij leeg is, blijft de lcore controleren op nieuwe pakketten. Daarom is dit model eerder geschikt voor een constant hoge belasting dan voor interfaces met sporadisch of sterk fluctuerend verkeer.

Pakketgegevens en metagegevens zijn opgeslagen in rte_mbuf-objecten. Deze zijn afkomstig uit een vooraf aangemaakte mempool en bevatten bijvoorbeeld de pakketlengte, de ingangspoort, offload-informatie en eventueel een RSS-hash. Vooraf gereserveerde pools, een vaste toewijzing van wachtrijen aan kernen en korte verwerkingspaden bevorderen Cache-locatie en vermijden onnodige gemeenschappelijke gegevensstructuren.

Zero Copy is echter geen automatische eigenschap van DPDK. Of en waar gegevens worden gekopieerd, hangt af van de NIC, het stuurprogramma, de offloads en de applicatielogica. Grote of gesegmenteerde frames kunnen bestaan uit meerdere gekoppelde mbufs; dit is bijvoorbeeld relevant bij jumbo-frames. Wie pakketgegevens herformatteert, samenvoegt of tussen incompatibele buffers overdraagt, moet rekening houden met mogelijke geheugenverplaatsingen in het eigen gegevenspad.

Architectuur, hulpbronnen en harde grenzen

De Environment Abstraction Layer, kortweg EAL, initialiseert DPDK en zorgt onder andere voor geheugenreservering, toegang tot apparaten, timers en de toewijzing van logische kernen. Op basis hiervan stelt de toepassing Ethernet-wachtrijen, mempools en de verwerking daarvan in. Een lcore is daarbij een voor DPDK geplande logische kern, niet zomaar een willekeurig rondzwervende applicatiethread. Deze fundamentele EAL-eigenschappen worden hier gestaafd door de documentatie van DPDK 25.07; versiespecifieke details moeten bovendien worden gecontroleerd voor de gebruikte release-tag.

Voor een rechtlijnig gegevenspad verwerkt een kern vaak een pakket volledig: van ontvangst via de beslissing tot verzending. Dit ‘run-to-completion’-model voorkomt overdrachten tussen kernen. Een pijplijn daarentegen verdeelt bijvoorbeeld het parseren, het zoeken naar de flow en het doorsturen in fasen. Deze kan verantwoordelijkheden ordenen, maar voegt wel lussen, synchronisatie en mogelijk een slechtere geheugenlokaliteit tussen de fasen toe.

Bij de planning moet ook rekening worden gehouden met NUMA. Queue, lcore en pakketpools moeten indien mogelijk op hetzelfde NUMA-knooppunt liggen, zodat het gegevenspad niet regelmatig toegang hoeft te krijgen tot het geheugen van een andere CPU-socket. De haalbare prestaties zijn bovendien afhankelijk van NIC-functies, de PCIe-verbinding, geheugenbandbreedte, CPU-kloksnelheid, pakketgrootte en de complexiteit van elke pakketbeslissing.

Een L4-load-balancer kan met behulp van DPDK IP- en poortgegevens snel gegevens analyseren, datastromen toewijzen en pakketten doorsturen. TLS-terminatie, complexe NAT-toestanden, logboekregistratie, health checks of trage backends worden hierdoor echter niet automatisch sneller. Ook heeft het control plane beschikbare CPU-tijd nodig voor configuratie, telemetrie en foutafhandeling. DPDK versnelt dus een duidelijk afgebakend datapad, maar niet noodzakelijkerwijs de gehele dienst.

Ook de grootte en levensduur van de pakketbuffers maken deel uit van de architectuur. Mempools beperken het aantal buffers dat tegelijkertijd beschikbaar is, terwijl de toepassing eigendomsoverdrachten correct moet beheren. Te klein gedimensioneerde pools kunnen onder belasting uitgeput raken; te grote reserveringen leggen beslag op het geheugen. De juiste omvang vloeit voort uit wachtrijen, burst-groottes, het pakketpad en verwachte piekbelastingen, niet uit een universele richtlijn.

Controleer de voorwaarden vóór het gebruik van de DPDK

DPDK is pas planbaar als de hardware, het geheugen en de CPU-toewijzing op elkaar zijn afgestemd. Een installatie op zich zorgt nog niet voor een krachtig gegevenspad: de PMD moet het specifieke NIC-model ondersteunen en er moeten resources voor de toepassing kunnen worden gereserveerd. De volgende toetsing maakt een onderscheid tussen technische minimumvereisten en aannames die pas gelden voor het daadwerkelijk gebruikte apparaat.

Hugepages zijn de gebruikelijke methode voor omvangrijke pakketpools, maar geen absolute voorwaarde voor elke DPDK-toepassing. De EAL ondersteunt ook –no-huge. Deze speciale modus is geen gelijkwaardige standaardaanbeveling: geschiktheid, geheugenbeheer en stuurprogramma-beperkingen moeten vóór de proefoperatie worden gecontroleerd. De hier gebruikte systeem- en EAL-basisprincipes worden beschreven in DPDK 25.07; vergelijk de opties bovendien met de daadwerkelijk geïnstalleerde release.

Bijzonder kritiek is de Apparaatbinding. Veel PMD’s vereisen dat de betreffende NIC wordt losgekoppeld van het reguliere kernelstuurprogramma en bijvoorbeeld wordt gekoppeld aan vfio-pci wordt toegewezen. De interface is dan niet meer op de gebruikelijke manier beschikbaar voor de normale Linux-netwerkstack. De concrete werkwijze moet echter wel aansluiten bij de PMD en mag niet zonder meer worden toegepast op elke ondersteunde netwerkkaart.

Een belangrijke uitzondering vormen de bifurcated PMD’s. In de documentatie van de driver wordt erop gewezen dat dergelijke PMD’s niet mogen worden losgekoppeld van de bijbehorende kernel-driver. De kernel-driver kan daarbij gekoppeld blijven, terwijl een datapad in de gebruikersruimte bepaalde bronnen gebruikt. De gelinkte, niet-versiegde documentatie heeft de ontwikkelingsstatus 26.11.0-rc1 en is geen versiegde handleiding voor 26.07. Controleer de apparaatondersteuning en de beschikbare kerneltools in de handleiding van de concreet gebruikte PMD.

Vóór elke wijziging geeft de volgende statusopvraging een overzicht van de PCI-apparaten en hun huidige stuurprogramma-toewijzing. De opvraging zelf wijzigt geen toewijzingen. Voer deze uit op het doelsysteem met het pad dat overeenkomt met de geïnstalleerde DPDK-bron- of toolstructuur.

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

Houd de toegang tot het beheer en het productieve gegevenspad gescheiden, zelfs als de gekozen PMD de kernel-driver niet vervangt. De bereikbaarheid via SSH of de console mag niet afhankelijk zijn van een interface waarvan de koppeling of de verkeersverdeling tijdens de proefperiode wordt gewijzigd. Een aparte beheerinterface, out-of-band-toegang of een vooraf geteste lokale noodroute beperkt het risico op een verkeerde configuratie.

DPDK, AF_XDP en kernelstack vergelijken

De keuze van het datapad is geen ranglijst, maar een operationele beslissing. De Linux-kernelstack, AF_XDP en DPDK hebben elk hun eigen invloed op de werklast, de toegang tot apparaten en het CPU-verbruik. De juiste optie hangt af van de vraag of de pakketsnelheid of de latentie in het netwerkpad daadwerkelijk de beperkende factor is – of dat de applicatie, de versleuteling en de backends de bottleneck vormen.

AF_XDP is een tussenoplossing voor teams die pakketten vroeg willen verwerken en toch dicht bij het Linux-netwerkmodel willen blijven. De kernel beschrijft zowel een kopieermodus als Zero Copy, waarvoor ondersteuning door de driver vereist is. Als Zero Copy expliciet wordt vereist, kan het aanmaken van de socket mislukken als de driver deze mogelijkheid niet biedt. Het artikel helpt bij het begrijpen van het XDP-niveau XDP en eXpress Data Path.

DPDK maakt daarentegen gebruik van ‘Poll Mode Drivers’ en verwerkt wachtrijen rechtstreeks vanuit de toepassing. Dit kan de socket- en interrupt-onderdelen van het DPDK-gegevenspad omzeilen, maar vereist wel dat de gebruiker zelf de verantwoordelijkheid neemt voor het geheugen, de wachtrijen en de kerneltoewijzing. Zero Copy Dit is noch een algemene prestatiegarantie, noch een automatisch kenmerk van een willekeurig DPDK-pad; het aantal kopieën hangt af van de toepassing, offloads en geheugenoverdrachten.

Kies de kernelstack als routing, firewalling, observability en eenvoudige bediening belangrijker zijn dan een gespecialiseerd pakketpad. Overweeg AF_XDP bij gerichte versnelling met kernelintegratie. DPDK is pas de moeite waard bij een aantoonbare behoefte aan een hoge pakketsnelheid of constante latentie, bestaande NIC-ondersteuning en een team dat de extra operationele verantwoordelijkheid op lange termijn kan dragen.

Wachtrijen, CPU-pinning en NUMA op een zinvolle manier plannen

Een robuuste Wachtrijtoewijzing begint met de nabijheid tussen NIC, CPU en geheugen. De EAL ondersteunt de selectie van logische kernen, geheugenreservering en apparaattoewijzing. Voor een eenvoudig gegevenspad is het meestal zinvol om een Rx-wachtrij vast toe te wijzen aan een lcore, de bijbehorende mempool op het lokale NUMA-knooppunt aan te maken en de verwerking vervolgens over te dragen aan een geschikte Tx-wachtrij. Deze basisinformatie over EAL is gedocumenteerd in de documentatie van DPDK 25.07 en moet voor versiespecifieke opties worden getoetst aan de gebruikte releasetag.

Een niet-productspecifiek voorbeeld van een host met twee NUMA-knooppunten zou zijn: de NIC op knooppunt 0 krijgt twee Rx-wachtrijen; elk lcore op knooppunt 0 verwerkt één wachtrij volledig. De pakketbuffers bevinden zich eveneens op knooppunt 0. Een andere, niet-pollende kern blijft vrij voor beheertaken, terwijl knooppunt 1 bestemd is voor andere diensten of duidelijk gescheiden gegevenspaden.

• Gegevenspad: per wachtrij een vast toegewezen lcore, lokale mempools en duidelijk benoemde Rx-/Tx-paren.
• Beheer: zorg ervoor dat er voldoende CPU-capaciteit beschikbaar blijft voor telemetrie, besturingslogica, gebeurtenissen en besturingssysteemdiensten.
• Reserve: Houd rekening met capaciteit voor piekbelastingen, foutopsporing en geplande uitbreidingen, in plaats van alle kernen permanent vol te plannen.

Deel een Rx-wachtrij niet over meerdere lcores. De PMD-richtlijn raadt het opsplitsen van Rx- en Tx-wachtrijen af, omdat de daarvoor benodigde globale vergrendelingen de prestaties aanzienlijk kunnen beïnvloeden. Gelijktijdige toegang van meerdere lcores tot een Tx-wachtrij is alleen als gedocumenteerde uitzondering voorzien als het stuurprogramma de mogelijkheid heeft om RTE_ETH_TX_OFFLOAD_MT_LOCKFREE meldt. Controleer deze capability voor de specifieke NIC-/PMD-combinatie; leid deze niet af uit de poortsnelheid of uit een algemene offload-schakelaar.

Een pijplijn met afzonderlijke parser-, classificatie- en verzendfasen kan de verantwoordelijkheden duidelijker maken. De gedocumenteerde pijplijnaanpak geeft pakketten via ringen door aan andere kernen; dit leidt tot extra geheugentoegangen en overdrachten. Voor eenvoudige filters of L4-doorsturing is „run-to-completion“ per wachtrij vaak gemakkelijker te plannen. Meerdere fasen moeten alleen worden ingezet als de taakverdeling de extra inspanning rechtvaardigt in het concrete belastingsprofiel.

Ook Hardware-offloads mogen niet in de planning worden meegenomen. Welke checksum-, segmentatie-, RSS- of flow-functies beschikbaar zijn, hangt af van de mogelijkheden van het specifieke Ethernet-apparaat en de bijbehorende PMD. Controleer dit vóór het ontwerp en behandel een ontbrekende offload als een normaal planningsgeval, niet als een uitzondering.

DPDK veilig in bedrijf houden

Voor het beheer van een DPDK-datapad zijn statistieken nodig die zowel de pakketverwerking als de beschikbare resources in ogenschouw nemen. Leg ten minste de verwerkte, afgewezen en foutieve pakketten vast, evenals applicatiespecifieke waarden voor verwerkingssnelheden, mempool-reserves en Latentieverdeling in plaats van slechts één gemiddelde waarde. Welke extra poort-, wachtrij- of stuurprogrammatellers beschikbaar zijn, hangt af van de specifieke PMD, de NIC en de toepassing en moet voor de gebruikte combinatie worden gecontroleerd.

Polling is een bewust doelconflict. Een lcore controleert voortdurend zijn Rx-wachtrij, zodat pakketten zonder het reguliere interruptpad kunnen worden verwerkt. Bij weinig of geen verkeer blijft de poll-lus niettemin actief. Houd daarom naast de CPU-capaciteit van de datapad-lcores ook rekening met CPU-capaciteit voor besturingslogica, telemetrie en het besturingssysteem. De aanvullend gebruikte EAL-documentatie heeft betrekking op DPDK 25.07; release-afhankelijke functies moeten worden gecontroleerd in de geïnstalleerde versie.

Voor de oorzaakanalyse is een temporele correlatie van belang. Als pakketverlies gelijktijdig optreedt met foutentellers, afnemende mempool-reserves of een overbelaste datapad-lcore, zijn dit in eerste instantie controleerbare aanwijzingen en nog geen eenduidig bewijs van de oorzaak. Schommelende responstijden kunnen onder andere verband houden met NUMA-ver verwijderd geheugen, concurrerende taken of pipeline-overdrachten. Vergelijk dergelijke hypothesen telkens met de kerntoewijzing, de wachtrijverdeling en de meetwaarden van hetzelfde tijdvenster.

Snelle registratie via de interface staat niet gelijk aan een volledige, permanent verliesvrije pakketregistratie. Voor flowstatistieken of headeranalyse kan een beperkte hoeveelheid metadata volstaan. Als elk pakket moet worden opgeslagen, worden de mogelijkheden bovendien beperkt door opslagbandbreedte, bufferruimte, schrijfdoorvoer en het gekozen opslagmedium. Gegevensbescherming en bewaarregels zijn daarbij onafhankelijke eisen die niet door de netwerkdoorvoer worden opgelost.

Plan virtuele machines en containers als een afzonderlijke integratietaak. Ga voor het specifieke platform na hoe toegang tot apparaten, opslagruimte, CPU-toewijzing en de benodigde rechten worden geregeld. Controleer deze combinatie met de gebruikte PMD, in plaats van voorbeeldparameters klakkeloos over te nemen. De gelinkte Linux-handleiding heeft momenteel de ontwikkelingsstatus 26.11.0-rc1; voor een productieve installatie is de documentatie van de daadwerkelijk geïnstalleerde release doorslaggevend.

Typische foutpatronen systematisch controleren

Bij het opsporen van fouten moet eerst een onderscheid worden gemaakt tussen waarneembare symptomen en mogelijke oorzaken. Wijzig niet tegelijkertijd de driverbinding, het aantal wachtrijen en de geheugenparameters, omdat de oorzaak dan niet meer te achterhalen is. Niet-destructieve tellers, inzicht in de configuratie en een vergelijking tussen de betreffende en niet-betrokken wachtrij leveren meestal de meest betrouwbare aanwijzingen op voordat er ingrepen worden gedaan.

Als er opvallend gedrag in de wachtrij wordt waargenomen, controleer je de eigenaar van de wachtrij en het NUMA-knooppunt van de mempool. In het ‘run-to-completion’-model verwerkt de toegewezen lcore het ontvangen, verwerken en verzenden; een pijplijn geeft pakketten door aan andere kernen. Verdeel de Rx-wachtrij echter niet over lcores. Gelijktijdige toegang tot een Tx-wachtrij is alleen mogelijk bij gemelde RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Deze functie is bedoeld als uitzondering. Een zelf ingestelde blokkering maakt het delen van wachtrijen niet tot een aanbevolen schaalbaarheidsstrategie.

Als er geen hardware-offloads beschikbaar zijn, is de juiste vraag niet alleen welke schakelaar is ingesteld, maar welke mogelijkheden het apparaat en de PMD daadwerkelijk bieden. Een toepassing kan een gewenste functie inplannen zonder dat deze voor dit model beschikbaar is. Vergelijk de ondersteuning voor de specifieke NIC met de tijdens de uitvoering gerapporteerde mogelijkheden, voordat je het gegevenspad afhankelijk maakt van deze offload.

De resultaten van testpmd moeten worden beschouwd als een basislijn of functionele test, en niet als een prestatiebewijs voor het latere gebruik. In de io-forwarding-modus worden pakketten ongewijzigd doorgestuurd, zonder dat de inhoud ervan wordt geëvalueerd voor technische verwerking. Parsers, flowtabellen, NAT, versleuteling en protocolstatus worden in deze modus niet weergegeven. De gelinkte, niet-versiegebonden documentatie heeft betrekking op 26.11.0-rc1; controleer het gedrag in de handleiding van de geïnstalleerde release. Noteer de forwarding-modus, de pakketgrootte, het aantal Rx-/Tx-wachtrijen en het aantal forwarding-kernen, en herhaal de vergelijking met de daadwerkelijke verwerkingslogica.

Implementatie, versiebeheer en beslissing over ingebruikname

Begin met een geïsoleerde test en een gedocumenteerde lastprofiel: pakketgroottes, piekbelasting, aantal stromen en benodigde verwerkingsstappen. Controleer de specifieke NIC, inclusief de bijbehorende Poll Mode-driver en de benodigde functies, aan de hand van het officiële hardwareoverzicht en de drivermatrix. Het feit dat een fabrikant in de lijst staat, betekent op zichzelf nog geen garantie voor elke kaart of alle offloads. Test vervolgens met echte applicatielogica, niet uitsluitend met een doorstuurvoorbeeld.

Noteer voor elke test de DPDK-versie, firmware, stuurprogramma’s, kernel en configuratie. Lees vóór een update de release-opmerkingen van de exacte release-tag die je wilt gebruiken en documenteer welke wijzigingen relevant zijn voor je eigen gegevenspad. Release-opmerkingen van verschillende versies zijn geen vervanging voor deze toewijzing, omdat functies en beperkingen tussen releases kunnen veranderen.

Een concreet aandachtspunt uit de release notes van DPDK 26.07 is het gewijzigde flush-/refill-algoritme van de mempool-cache: de effectieve grootte ervan komt sindsdien overeen met de geconfigureerde grootte; voorheen was deze 50 procent groter. Alleen wanneer elke lcore uit een mempool uitsluitend objecten ophaalt of uitsluitend teruggeeft, wordt in de release notes aanbevolen om de geconfigureerde cachegrootte te verdubbelen, om een mogelijke verdubbeling van het cache-miss-percentage te voorkomen. Dit geldt bijvoorbeeld voor pijplijnen met afzonderlijke Rx- en Tx-lcores, niet in het algemeen voor „run-to-completion“. De wijziging heeft betrekking op release 26.07; de gelinkte historische releasepagina staat inmiddels in de documentatie bij 26.11.0-rc1.

Begin met een beperkte proef en vaste stopcriteria. Vergelijk de doorvoer, hoge latentiepercentielen, pakketverlies en CPU-behoefte onder dezelfde omstandigheden met de huidige bedrijfsvoering. Controleer de monitoring, herstarts en het terugvallen naar de vorige configuratie. Houd rekening met de operationele kosten; hieruit kan geen algemene doorvoergarantie worden afgeleid.

DPDK is vooral de moeite waard als keuze voor implementatie wanneer de gemeten voordelen de extra onderhoudskosten rechtvaardigen. Voor de inpassing in het omringende systeemplatform vult dit artikel aan Linux-kernel in een hostingomgeving de planning. Houd bij gewone hostingdiensten ook het bestaande netwerkpad als vergelijkingsbasis in de test aan.