DPDK: Att planera paketbehandlingen i användarutrymmet på rätt sätt

DPDK:s grundprincip och korrekt klassificering

DPDK är ett ramverk för applikationer som behöver bearbeta nätverkspaket med så liten overhead som möjligt i användarutrymmet. I stället för att använda den vanliga vägen via kärnans nätverksstack, socklar och dess paketstrukturer kan en applikation använda utvalda nätverkskort direkt för sin egen dataväg. Detta syftar framför allt till höga pakethastigheter, låg latens och välplanerbar bearbetning vid många små paket.

Formuleringen „utan kärnbegränsningar“ är här en förenkling. Linux-kärnan finns kvar för operativsystemet, minneshanteringen, processerna, säkerheten och ett stort antal administrativa uppgifter. DPDK ersätter inte heller nätverkskortets begränsningar eller begränsningar vad gäller PCIe, minnesbandbredd eller CPU. För bundna gränssnitt kringgår det framför allt den vanliga datavägen i kärnan och flyttar pakethanteringen till en specialiserad applikation.

I den vanliga nätverksvägen i Linux samverkar nätverksdrivrutiner, NAPI, pakethantering och socket-lagret. Denna väg är inte generellt sett enbart avbrottsbaserad. En DPDK-Poll Mode Driver hämtar mottagningsköer direkt från användarutrymmet. Applikationen tar emot paket i grupper, kontrollerar eller ändrar dem och vidarebefordrar dem därefter till en sändningskö eller ett nästa bearbetningssteg.

Detta är ingen allmän kärnoptimering och brukar inte vara den första åtgärden för en vanlig webbapplikation med få TCP-anslutningar. Först när paketdatavägen i sig visar sig vara begränsande, till exempel vid L4-lastbalansering, filtrering eller tunneländpunkter, motiverar den potentiella vinsten den extra driftsinsatsen. Versionsberoende egenskaper måste kontrolleras mot dokumentationen för den specifika release-taggen som används; en release candidate kan inte likställas med en release som används i produktion.

Hur paketvägen i användarutrymmet fungerar

Vid ingången konfigurerar applikationen en eller flera Rx-köer för nätverkskortet. En tilldelad exekveringskärna avfrågar en kö i en loop och tar emot en burst av tillgängliga paket. Dessa Burst-bearbetning minskar antalet funktionsanrop och administrationsarbetet per paket. Efter klassificering, vidarebefordran eller ändring placerar applikationen paketen samlade i en Tx-kö.

Polling undviker många avbrottsväxlingar i den hårt belastade datavägen och gör en kärnas arbete mer förutsägbart. Nackdelen är att CPU:n är kontinuerligt aktiv: även när kön är tom fortsätter lcore att söka efter nya paket. Därför passar denna modell bättre för en konstant hög belastning än för gränssnitt med sällsynt eller starkt varierande trafik.

Paketdata och metadata finns i rte_mbuf-objekt. Dessa hämtas från en i förväg skapad mempool och innehåller till exempel paketlängd, ingångsport, avlastningsinformation och, i förekommande fall, en RSS-hash. I förväg reserverade pooler, en fast tilldelning mellan kö och kärna samt korta bearbetningsvägar främjar Cache-plats och undviker onödiga gemensamma datastrukturer.

Zero Copy är dock inte en automatisk egenskap hos DPDK. Om och var data kopieras beror på nätverkskortet, drivrutinen, avlastningsfunktionerna och applikationslogiken. Stora eller segmenterade ramar kan bestå av flera sammanlänkade mbufs; detta är till exempel relevant vid jumboramar. Den som omformaterar, sammanfogar eller överför paketdata mellan inkompatibla buffertar måste ta hänsyn till eventuella minnesförflyttningar i sin egen dataväg.

Arkitektur, resurser och hårda gränser

Environment Abstraction Layer, förkortat EAL, initialiserar DPDK och tillhandahåller bland annat minnesreservering, enhetsåtkomst, timers samt tilldelning av logiska kärnor. På denna grundval konfigurerar applikationen Ethernet-köer, minnespooler och deras bearbetning. En lcore är i detta sammanhang en logisk kärna som är schemalagd för DPDK, inte bara en godtyckligt rörlig applikationstråd. Dessa grundläggande EAL-egenskaper styrs här av dokumentationen för DPDK 25.07; versionsberoende detaljer måste dessutom kontrolleras för den använda release-taggen.

För en rak dataväg bearbetar ofta en kärna ett paket i sin helhet: från mottagning via beslut till sändning. Denna ”run-to-completion”-modell undviker överlämningar mellan kärnor. En pipeline delar däremot upp exempelvis parsning, flödessökning och vidarebefordran i olika steg. Den kan organisera ansvarsområden, men medför ringar, synkronisering och potentiellt sämre minneslokalitet mellan stegen.

Planeringen måste även ta hänsyn till NUMA. Queue, lcore och paketpooler bör om möjligt placeras på samma NUMA-nod, så att datavägen inte regelbundet behöver hämta data från minnet på ett annat CPU-sockel. Den prestanda som kan uppnås beror dessutom på NIC-funktioner, PCIe-anslutning, minnesbandbredd, CPU-klockfrekvens, paketstorlek och komplexiteten i varje paketbeslut.

En L4-lastbalanserare kan med hjälp av IP- och portinformation från DPDK snabbt analysera, tilldela flöden och vidarebefordra paket. TLS-terminering, komplexa NAT-tillstånd, loggning, hälsokontroller eller långsamma backend-system blir dock inte automatiskt snabbare på så sätt. Kontrollplanet behöver dessutom tillgänglig CPU-tid för konfiguration, telemetri och felhantering. DPDK påskyndar följaktligen en tydligt avgränsad dataväg, men inte nödvändigtvis hela tjänsten.

Även storleken och livslängden på paketbuffertarna ingår i arkitekturen. Mempools begränsar hur många buffertar som är tillgängliga samtidigt, medan applikationen måste hantera ägarbyten på ett korrekt sätt. För små buffertpooler kan ta slut under hög belastning; alltför stora reserveringar binder upp minne. Den lämpliga storleken bestäms av köer, burst-storlekar, paketvägar och förväntade belastningstoppar, inte av en universell standard.

Kontrollera förutsättningarna innan DPDK-insatsen

DPDK kan planeras först när hårdvara, minne och CPU-tilldelning stämmer överens. En installation i sig skapar inte en effektiv dataväg: PMD måste stödja den specifika NIC-modellen, och resurser måste kunna reserveras för applikationen. Följande kontroll skiljer tekniska minimikrav från antaganden som endast gäller för den enhet som faktiskt används.

Hugepages är det vanliga tillvägagångssättet för omfattande paketpooler, men inget absolut krav för alla DPDK-applikationer. EAL stöder även –no-huge. Detta specialläge är inte en likvärdig standardrekommendation: lämplighet, minneshantering och drivrutinsbegränsningar måste kontrolleras innan pilotdriften påbörjas. De system- och EAL-grunder som används här dokumenteras i DPDK 25.07; jämför dessutom alternativen med den faktiskt installerade versionen.

Särskilt kritisk är Enhetsbindning. Många PMD:er förutsätter att det aktuella nätverkskortet kopplas bort från den vanliga kärndrivrutinen och till exempel ansluts till vfio-pci binds. Gränssnittet är då inte längre tillgängligt för den vanliga Linux-nätverksstacken. Det konkreta tillvägagångssättet måste dock anpassas till PMD och får inte tillämpas generellt på alla nätverkskort som stöds.

Ett viktigt undantag utgörs av förgrenade PMD:er. I drivrutinsdokumentationen påpekas att sådana PMD:er inte ska kopplas bort från den tillhörande kärndrivrutinen. Kärndrivrutinen kan då förbli bunden medan en dataväg i användarutrymmet utnyttjar vissa resurser. Den länkade, icke-versionsspecifika dokumentationen avser utvecklingsversionen 26.11.0-rc1 och är inte en versionsspecifik handledning för 26.07. Kontrollera enhetsstöd och tillgängliga kärnverktyg i handboken för just den PMD som används.

Innan varje ändring ger följande statusförfrågan en översikt över PCI-enheterna och deras aktuella drivrutinskopplingar. Den ändrar inte själv någon koppling. Kör den på målsystemet med den sökväg som motsvarar den installerade DPDK-käll- eller verktygsstrukturen.

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

Planera så att åtkomst till hanteringsgränssnittet och produktionsdatavägen hålls åtskilda, även om den valda PMD:n inte ersätter kärndrivrutinen. Tillgängligheten via SSH eller konsolen får inte vara beroende av ett gränssnitt vars koppling eller trafikfördelning ändras under pilotdriften. Ett separat förvaltningsgränssnitt, åtkomst utanför bandbredden eller en i förväg testad lokal nödväg begränsar risken för felkonfiguration.

Jämförelse mellan DPDK, AF_XDP och Kernelstack

Valet av dataväg är inte en rangordning, utan ett driftsbeslut. Linux-kärnstacken, AF_XDP och DPDK påverkar var och en arbetsinsats, enhetsåtkomst och CPU-förbrukning. Vilket alternativ som är lämpligt beror på om det faktiskt är paketfrekvensen eller latensen i nätverksvägen som utgör begränsningen – eller om applikationen, krypteringen och backend-komponenterna utgör flaskhalsen.

AF_XDP är ett mellanliggande alternativ för team som vill hantera paket tidigt men ändå hålla sig nära Linux-nätverksmodellen. Kärnan beskriver ett kopieringsläge samt Zero Copy, vilket kräver drivrutinsstöd. Om Zero Copy uttryckligen krävs kan skapandet av socketen misslyckas om drivrutinen inte stöder denna funktion. Artikeln nedan hjälper till att förstå XDP-nivån XDP och eXpress Data Path.

DPDK använder däremot drivrutiner i poll-läge och bearbetar köer direkt från applikationen. Detta gör det möjligt att kringgå socket- och interrupt-komponenterna i DPDK:s dataväg, men kräver att man själv ansvarar för minne, köer och kärntilldelning. Zero Copy Detta är varken ett allmänt prestandalöfte eller en automatisk egenskap hos vilken DPDK-väg som helst; antalet kopior beror på applikationen, avlastningar och minnesöverföringar.

Välj kernelstacken om routing, brandväggsfunktioner, övervakningsmöjligheter och enkel drift är viktigare än en specialiserad paketväg. Överväg AF_XDP vid målinriktad acceleration med kärnanslutning. DPDK lönar sig först vid ett påvisat behov av hög pakethastighet eller jämn latens, befintligt NIC-stöd och ett team som på lång sikt kan axla det extra driftsansvaret.

Planera köer, CPU-pinning och NUMA på ett genomtänkt sätt

En tålig Kö-tilldelning börjar med närheten mellan NIC, CPU och minne. EAL stöder val av logiska kärnor, minnesreservering och enhetskonfiguration. För en enkel dataväg är det oftast lämpligt att fast tilldela en Rx-kö till en lcore, skapa den tillhörande minnespoolen på den lokala NUMA-noden och därefter överföra bearbetningen till en lämplig Tx-kö. Dessa grundläggande EAL-uppgifter stöds av dokumentationen för DPDK 25.07 och måste kontrolleras mot den använda release-taggen för versionsberoende alternativ.

Ett icke-produktspecifikt exempel på en värd med två NUMA-noder skulle kunna vara följande: Nätverkskortet på nod 0 tilldelas två mottagningsköer; en lcore på nod 0 hanterar varje kö i sin helhet. Paketbuffertarna finns också på nod 0. En ytterligare kärna, som inte utför polling, förblir ledig för administrativa uppgifter, medan nod 1 är avsedd för andra tjänster eller tydligt åtskilda datavägar.

• Dataväg: en fast tilldelad lcore per kö, lokala minnespooler och tydligt namngivna Rx-/Tx-par.
• Administration: Se till att det finns tillräcklig CPU-kapacitet för telemetri, styrlogik, händelser och operativsystemstjänster.
• Reserv: Planera in kapacitet för belastningstoppar, felsökning och planerade utbyggnader, istället för att permanent planera in alla kärnor.

Dela inte en Rx-kö mellan flera lcores. PMD-guiden avråder från att dela upp Rx- och Tx-köer, eftersom de globala lås som krävs för detta kan påverka prestandan avsevärt. Samtidig åtkomst till en Tx-kö från flera lcores är endast avsedd som ett dokumenterat undantag om drivrutinen har förmågan att RTE_ETH_TX_OFFLOAD_MT_LOCKFREE rapporterar. Kontrollera denna kapacitet för den specifika NIC-/PMD-kombinationen; dra inga slutsatser utifrån varken porthastigheten eller en allmän avlastningsknapp.

En pipeline med separata steg för parsning, klassificering och sändning kan göra ansvarsfördelningen tydligare. Den dokumenterade pipeline-metoden vidarebefordrar paket via ringar till ytterligare kärnor, vilket medför ytterligare minnesåtkomst och överföringar. För enkla filter eller L4-vidarebefordran är det ofta enklare att planera en ”run-to-completion”-strategi per kö. Flera steg bör endast användas om arbetsfördelningen motiverar den extra arbetsinsatsen i det konkreta belastningsprofilen.

Dessutom Hårdvaruavlastning får inte beaktas i planeringen. Vilka funktioner för kontrollsumma, segmentering, RSS eller flöde som finns tillgängliga beror på kapaciteten hos den specifika Ethernet-enheten och dess PMD. Kontrollera dessa före utformningen och behandla en utebliven avlastning som ett normalt planeringsfall, inte som ett undantag.

Säker övervakning av DPDK under drift

För att driva en DPDK-dataväg krävs mätvärden som beaktar både paketbearbetning och resurser. Registrera åtminstone bearbetade, avvisade och felaktiga paket samt applikationsspecifika värden för bearbetningshastigheter, mempool-reserver och Latensfördelning istället för endast ett medelvärde. Vilka ytterligare port-, kö- eller drivrutinsräknare som finns tillgängliga beror på den specifika PMD:n, nätverkskortet och applikationen och måste kontrolleras för den kombination som används.

Polling innebär en medveten målkonflikt. En lcore avfrågar kontinuerligt sin Rx-kö så att paket kan bearbetas utan den vanliga avbrottsvägen. Även vid liten eller ingen trafik förblir pollingslingan ändå aktiv. Planera därför in CPU-kapacitet för styrlogik, telemetri och operativsystem utöver datavägs-lcore-enheterna. Den kompletterande EAL-dokumentationen avser DPDK 25.07; versionberoende funktioner måste kontrolleras i den installerade versionen.

För orsaksanalysen är en tidsmässig korrelation viktig. Om paketförlust inträffar samtidigt med felräknare, minskande mempool-reserver eller en fullbelagd dataväg-lcore, är detta i första hand kontrollerbara indikationer och ännu inget entydigt bevis på orsaken. Fluktuerande svarstider kan bland annat ha samband med minne som ligger långt bort från NUMA, konkurrerande uppgifter eller pipeline-överlämningar. Jämför sådana hypoteser med kärntilldelning, köfördelning och mätvärden från samma tidsfönster.

Snabb registrering vid gränssnittet är inte detsamma som fullständig, kontinuerlig och förlustfri paketregistrering. För flödesstatistik eller utvärdering av rubriker kan en liten mängd metadata räcka. Om varje paket ska sparas begränsar dessutom lagringsbandbredd, buffertvolym, skrivhastighet och det valda lagringsmediet systemets uppbyggnad. Dataskydd och lagringsregler är i detta sammanhang oberoende krav som nätverksgenomströmningen inte löser.

Planera virtuella maskiner och containrar som en separat integrationsuppgift. Ta reda på hur enhetsåtkomst, lagringsutrymme, CPU-tilldelning och nödvändiga behörigheter tillhandahålls för den specifika plattformen. Testa denna kombination med den använda PMD:n istället för att generellt överta exempelparametrarna. Den länkade Linux-guiden gäller för närvarande utvecklingsversionen 26.11.0-rc1; för en produktiv installation är dokumentationen för den faktiskt installerade versionen avgörande.

Systematiskt kontrollera typiska felmönster

Vid felsökning bör man först skilja mellan observerbara symptom och möjliga orsaker. Ändra inte drivrutinsinställningar, köantal och minnesparametrar samtidigt, eftersom det då blir omöjligt att spåra vad som utlöste felet. Icke-destruktiva räknare, inblick i konfigurationen och en jämförelse mellan den drabbade och den icke-drabbade kön ger oftast de mest tillförlitliga ledtrådarna innan åtgärder vidtas.

Om köbeteendet verkar onormalt ska du kontrollera köägaren och mempoolens NUMA-nod. I Run-to-completion-modellen hanterar den tilldelade lcore mottagning, bearbetning och sändning; en pipeline vidarebefordrar paket till ytterligare kärnor. Dela dock inte Rx-kön mellan lcores. Samtidig åtkomst till en Tx-kö är endast tillåten vid rapporterad RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Funktionen är avsedd som ett undantag. En spärr som man själv lägger till gör att ködelning inte är en rekommenderad skalningsstrategi.

Om det saknas hårdvaruavlastning är den rätta frågan inte enbart vilken flagga som har satts, utan vilka funktioner enheten och PMD:n faktiskt tillhandahåller. En applikation kan planera in en önskad funktion utan att den är tillgänglig för just den här modellen. Jämför stödet för det specifika nätverkskortet med de funktioner som rapporteras vid körning innan du gör datavägen beroende av denna avlastning.

Resultaten från testpmd ska betraktas som en baslinje eller funktionskontroll, inte som ett bevis på prestanda i den senare användningen. I io-Forwarding-läget vidarebefordras paket oförändrade, utan att deras innehåll utvärderas för teknisk bearbetning. Parsare, flödestabeller, NAT, kryptering och protokollstatus återges inte i detta läge. Den länkade, icke-versionerade dokumentationen avser 26.11.0-rc1; kontrollera beteendet i handboken för den installerade versionen. Notera vidarebefordringsläge, paketstorlek, antal Rx-/Tx-köer och antal vidarebefordringskärnor och upprepa jämförelsen med den faktiska bearbetningslogiken.

Lansering, versionshantering och beslut om driftsättning

Börja med ett isolerat test och en dokumenterad lastprofil: Paketstorlekar, toppbelastning, antal flöden och nödvändiga bearbetningssteg. Kontrollera det specifika NIC-kortet samt tillhörande Poll Mode-drivrutin och nödvändiga funktioner med hjälp av den officiella hårdvaruöversikten och drivrutinsmatrisen. Att en tillverkare finns med på listan bekräftar varken varje kort eller alla avlastningsfunktioner. Testa därefter med verklig applikationslogik, inte enbart med ett vidarebefordringsexempel.

Notera DPDK-version, firmware, drivrutiner, kärna och konfiguration för varje test. Läs releaseanteckningarna för just den release-tag som ska användas innan du gör en uppdatering och dokumentera vilka ändringar som är relevanta för din egen dataväg. Releaseanteckningar för olika versioner ersätter inte denna kartläggning, eftersom funktioner och begränsningar kan variera mellan olika releaser.

En konkret punkt att beakta från releaseanteckningarna för DPDK 26.07 är den ändrade flushing-/refill-algoritmen för mempool-cachen: dess effektiva storlek motsvarar numera den konfigurerade storleken; tidigare var den 50 procent större. Endast om varje lcore i en mempool uteslutande hämtar eller returnerar objekt rekommenderar releaseanteckningarna att den konfigurerade cache-storleken fördubblas för att undvika en eventuell fördubbling av cache-miss-frekvensen. Detta gäller till exempel pipelines med separata Rx- och Tx-lcores, inte generellt Run-to-completion. Ändringen gäller version 26.07; den länkade historiska versionssidan finns numera i dokumentationen för 26.11.0-rc1.

Börja med ett begränsat pilotprojekt och fasta avbrottskriterier. Jämför genomströmning, höga latenspercentiler, paketförluster och CPU-behov under samma förhållanden som den tidigare driften. Kontrollera övervakning, omstarter och återgång till den tidigare konfigurationen. Beakta driftskostnaderna; en allmän genomströmningsgaranti kan inte härledas från detta.

DPDK är ett lönsamt val framför allt då den uppmätta nyttan motiverar den extra underhållsinsatsen. För att placera den i den omgivande systemplattformen kompletterar artikeln Linux-kärnan i webbhotellverksamhet Planeringen. Behåll även den befintliga nätverksvägen som jämförelsegrund i testet för vanliga webbhotellstjänster.