DPDK: Korrekt planlægning af pakkehåndtering i brugerrummet

DPDK-grundprincippet og korrekt klassificering

DPDK er et framework til applikationer, der skal behandle netværkspakker med så lidt overhead som muligt i brugerrummet. I stedet for at benytte den sædvanlige vej via kernelens netværksstack, sockets og deres pakkestrukturer kan en applikation bruge udvalgte netværkskort direkte til sin egen datavej. Dette sigter især mod høje pakkehastigheder, lave latenstider og en let planlægbar behandling af mange små pakker.

Udtrykket „uden kernelbegrænsninger“ er her en forenkling. Linux-kernelen er stadig til stede til at varetage operativsystemet, hukommelsesstyring, processer, sikkerhed og en lang række administrative opgaver. DPDK erstatter heller ikke begrænsninger i netværkskortet eller PCIe-, hukommelsesbåndbredde- eller CPU-begrænsninger. For bundne grænseflader omgår det først og fremmest den sædvanlige kernel-datavej og flytter pakkehåndteringen over til en specialiseret applikation.

I den almindelige Linux-netværkssti samarbejder netværksdrivere, NAPI, pakkehåndtering og socket-laget. Denne sti er ikke generelt set udelukkende interrupt-baseret. En DPDK-Afstemning: Mode Driver henter modtagelseskøer direkte fra brugerrummet. Applikationen modtager pakker i grupper, kontrollerer eller ændrer dem og videresender dem derefter til en afsendelseskø eller et yderligere behandlingstrin.

Dette er ikke en generel kerneoptimering, og for en almindelig webapplikation med få TCP-forbindelser er det som regel ikke den første foranstaltning, man bør træffe. Først når selve pakkedatavejen påviseligt er begrænset, f.eks. ved L4-lastfordeling, filtrering eller tunnelendepunkter, retfærdiggør den mulige gevinst den ekstra driftsindsats. Versionsafhængige egenskaber skal sammenlignes med dokumentationen for den konkret anvendte release-tag; en release candidate kan i den forbindelse ikke sidestilles med en release, der anvendes i produktion.

Sådan fungerer pakkestien i brugerrummet

Ved indgangen konfigurerer applikationen en eller flere Rx-køer på netværkskortet. En tildelt kerner afspørger en kø i en løkke og modtager en burst af tilgængelige pakker. Disse Burst-behandling reducerer antallet af funktionskald og administrationsbyrden pr. pakke. Efter klassificering, videresendelse eller ændring placerer applikationen pakkerne samlet i en Tx-kø.

Polling undgår mange interrupt-skift i den stærkt belastede datavej og gør en kernes arbejde mere forudsigeligt. Ulempen er, at CPU’en er konstant aktiv: Selv når køen er tom, fortsætter lcore med at tjekke for nye pakker. Derfor egner denne model sig bedre til en konstant høj belastning end til grænseflader med sjælden eller stærkt svingende trafik.

Pakkedata og metadata findes i rte_mbuf-objekter. Disse stammer fra en på forhånd oprettet mempool og indeholder eksempelvis pakkelængde, indgangsport, offload-oplysninger og eventuelt en RSS-hash. På forhånd reserverede puljer, en fast tildeling af køer til kerner og korte behandlingsveje fremmer Cache-placering og undgår unødvendige fælles datastrukturer.

Zero Copy er dog ikke en automatisk DPDK-egenskab. Om og hvor data kopieres, afhænger af NIC, driver, offloads og applikationslogik. Store eller segmenterede frames kan bestå af flere sammenkædede mbufs; dette er f.eks. relevant ved jumbo-frames. Den, der omformer, sammenfører eller overfører pakkedata mellem inkompatible buffere, skal tage højde for mulige hukommelsesflytninger i sin egen datavej.

Arkitektur, ressourcer og faste grænser

Environment Abstraction Layer, forkortet EAL, initialiserer DPDK og sørger blandt andet for hukommelsesreservation, enhedsadgang, timere samt tildeling af logiske kerner. På dette grundlag konfigurerer applikationen Ethernet-køer, mempools og deres behandling. En lcore er her en logisk kerne, der er planlagt til DPDK, og ikke blot en vilkårlig vandrende applikationstråd. Disse grundlæggende EAL-egenskaber er her dokumenteret i DPDK 25.07; versionsafhængige detaljer skal desuden kontrolleres for den anvendte release-tag.

For at sikre en lige datavej behandler en kerne ofte en pakke fuldt ud: fra modtagelse over beslutning til afsendelse. Denne »run-to-completion«-model undgår overdragelser mellem kerner. En pipeline opdeler derimod f.eks. parser, flow-søgning og videresendelse i trin. Den kan organisere ansvarsområder, men tilføjer ringe, synkronisering og potentielt dårligere hukommelseslokalitet mellem trinene.

Planlægningen skal også tage højde for NUMA. Queue, lcore og pakkepooler bør så vidt muligt være placeret på samme NUMA-node, så datavejen ikke regelmæssigt skal hente data fra hukommelsen på en anden CPU-sokkel. Den opnåelige ydeevne afhænger desuden af NIC-funktioner, PCIe-forbindelse, hukommelsesbåndbredde, CPU-klokfrekvens, pakkestørrelse og kompleksiteten af hver enkelt pakkebeslutning.

En L4-load-balancer kan ved hjælp af DPDK hurtigt analysere IP- og portoplysninger, tildele datastrømme og videresende pakker. TLS-terminering, komplekse NAT-tilstande, logning, sundhedstjek eller langsomme backends bliver dog ikke automatisk hurtigere af den grund. Ligeledes har kontrolplanet brug for tilgængelig CPU-tid til konfiguration, telemetri og fejlhåndtering. DPDK fremskynder derfor en klart afgrænset datavej, ikke nødvendigvis hele tjenesten.

Også størrelsen og levetiden for pakkebufferne er en del af arkitekturen. Mempools begrænser, hvor mange buffere der er tilgængelige på samme tid, mens applikationen skal administrere ejerskift korrekt. For små puljer kan blive opbrugt under belastning; for store reserver binder hukommelse. Den fornuftige størrelse afhænger af køer, burst-størrelser, pakkerute og forventede belastningsspidser, ikke af en universel standard.

Kontroller forudsætningerne inden anvendelse af DPDK

DPDK kan først planlægges, når hardware, hukommelse og CPU-tildeling passer sammen. En installation i sig selv skaber ikke en effektiv datavej: PMD’en skal understøtte den konkrete NIC-model, og ressourcerne skal kunne reserveres til applikationen. Den følgende gennemgang skelner mellem tekniske minimumskrav og antagelser, der kun gælder for den enhed, der faktisk anvendes.

Hugepages er den sædvanlige fremgangsmåde for omfattende pakkepooler, men ikke en betingelse, der gælder uden undtagelse for alle DPDK-applikationer. EAL understøtter også –no-huge. Denne særlige tilstand er ikke en standardanbefaling: Egnethed, hukommelsesstyring og driverbegrænsninger skal kontrolleres inden pilotdrift. De her anvendte system- og EAL-grundlag er dokumenteret i DPDK 25.07; sammenlign desuden indstillingerne med den faktisk installerede version.

Særligt kritisk er Enhedsbinding. Mange PMD’er forudsætter, at det pågældende NIC afkobles fra den almindelige kerne-driver og f.eks. tilsluttes til vfio-pci bindes. Grænsefladen er derefter ikke længere tilgængelig som normalt for den almindelige Linux-netværksstack. Den konkrete fremgangsmåde skal dog passe til PMD’en og må ikke generelt overføres til alle understøttede netværkskort.

En vigtig undtagelse er bifurkerede PMD’er. Driverdokumentationen påpeger, at sådanne PMD’er ikke bør frigøres af den tilhørende kerne-driver. Her kan kerne-driveren forblive bundet, mens en datavej i brugerrummet benytter bestemte ressourcer. Den linkede, ikke-versionsspecifikke dokumentation afspejler udviklingsstatus 26.11.0-rc1 og er ikke en versionsspecifik vejledning til 26.07. Kontroller enhedsunderstøttelse og tilgængelige kerneværktøjer i manualen til den konkrete PMD, der anvendes.

Før hver ændring giver følgende statusforespørgsel en oversigt over PCI-enhederne og deres aktuelle driver-tilknytning. Den ændrer ikke selv nogen tilknytning. Kør den på målsystemet med den sti, der passer til den installerede DPDK-kilde- eller værktøjsstruktur.

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

Adgangen til Plane Management og produktivdatastien skal være adskilt, selvom den valgte PMD ikke erstatter kerne-driveren. Adgangen via SSH eller konsollen må ikke afhænge af en grænseflade, hvis tilknytning eller trafikfordeling ændres under pilotdriften. En separat administrationsgrænseflade, out-of-band-adgang eller en på forhånd testet lokal nødvej begrænser risikoen for fejlkonfiguration.

Sammenligning af DPDK, AF_XDP og kernelstakken

Valget af datavej er ikke en rangliste, men en driftsbeslutning. Linux-kernelstakken, AF_XDP og DPDK påvirker hver især arbejdsbyrden, enhedsadgangen og CPU-forbruget. Den rette løsning afhænger af, om det rent faktisk er pakkehastigheden eller latenstiden i netværksstien, der udgør begrænsningen – eller om det er applikationen, krypteringen og backend-systemerne, der udgør flaskehalsen.

AF_XDP er en mellemvej for teams, der ønsker at behandle pakker tidligt, men alligevel holde sig tæt på Linux-netværksmodellen. Kernen beskriver en kopieringsmodus samt Zero Copy, som kræver driverunderstøttelse. Hvis Zero Copy udtrykkeligt kræves, kan oprettelsen af en socket mislykkes, hvis driveren ikke understøtter denne funktion. Artiklen hjælper med at forstå XDP-laget XDP og eXpress Data Path.

DPDK bruger derimod Poll Mode Drivers og behandler køer direkte fra applikationen. Dette kan omgå socket- og interrupt-komponenterne i DPDK-datavejen, men kræver, at man selv tager ansvaret for hukommelse, køer og kerneallokering. Zero Copy Dette er hverken et generelt løfte om ydeevne eller en automatisk egenskab ved en vilkårlig DPDK-sti; antallet af kopier afhænger af applikationen, offloads og hukommelsesoverførsler.

Vælg kernelstakken, hvis routing, firewall, overvågning og enkel drift er vigtigere end en specialiseret pakkerute. Overvej AF_XDP ved målrettet acceleration med kernel-integration. DPDK er først en god investering, hvis der er et konkret behov for høj pakkehastighed eller ensartet latenstid, eksisterende NIC-understøttelse og et team, der på lang sigt kan påtage sig det ekstra driftsansvar.

Planlægning af køer, CPU-pinning og NUMA på en fornuftig måde

En robust Kø-tildeling begynder med den fysiske nærhed mellem NIC, CPU og hukommelse. EAL understøtter valg af logiske kerner, hukommelsesreservation og enhedstildeling. For at opnå en enkel datavej er det som regel hensigtsmæssigt at tildele en Rx-kø fast til en lcore, oprette den tilhørende mempool på den lokale NUMA-node og derefter overføre behandlingen til en passende Tx-kø. Disse grundlæggende EAL-oplysninger er dokumenteret i DPDK 25.07 og skal kontrolleres i forhold til den anvendte release-tag for versionsafhængige indstillinger.

Et ikke-produktspecifikt eksempel på en host med to NUMA-noder kunne være: NIC’en på node 0 modtager to Rx-køer; én lcore på node 0 behandler hver kø fuldstændigt. Pakkebufferne befinder sig ligeledes på node 0. En yderligere kerne, der ikke udfører polling, forbliver ledig til administrative opgaver, mens node 1 er forbeholdt andre tjenester eller klart adskilte dataveje.

• Datastien: én fast tildelt lcore pr. kø, lokale mempools og tydeligt navngivne Rx-/Tx-par.
• Administration: Sørg for, at der er ledig CPU-kapacitet til telemetri, styringslogik, hændelser og operativsystemtjenester.
• Reserve: Planlæg kapacitet til spidsbelastninger, fejlfinding og planlagte udvidelser i stedet for at udnytte alle kerner fuldt ud hele tiden.

Del ikke en Rx-kø mellem flere lcores. PMD-vejledningen fraråder opdeling af Rx- og Tx-køer, da de globale låse, der er nødvendige herfor, kan påvirke ydeevnen betydeligt. Samtidig adgang for flere lcores til en Tx-kø er kun forudset som en dokumenteret undtagelse, hvis driveren har evnen til RTE_ETH_TX_OFFLOAD_MT_LOCKFREE rapporteres. Kontroller denne kapacitet for den konkrete NIC-/PMD-kombination; udled den hverken ud fra porthastigheden eller en generel offload-kontakt.

En pipeline med adskilte trin til parsing, klassificering og afsendelse kan gøre ansvarsfordelingen mere overskuelig. Den dokumenterede pipeline-tilgang videresender pakker via ringe til yderligere kerner; dette medfører yderligere hukommelsesadgange og overførsler. Ved enkle filtre eller L4-videresendelse er »run-to-completion« pr. kø ofte nemmere at planlægge. Flere trin bør kun anvendes, hvis arbejdsfordelingen retfærdiggør den ekstra indsats i det konkrete belastningsprofil.

Også Hardware-aflastninger må ikke inddrages i planlægningen. Hvilke checksum-, segmenterings-, RSS- eller flow-funktioner der er tilgængelige, afhænger af det konkrete Ethernet-udstyrs kapacitet og dets PMD. Kontroller dem inden udformningen, og behandl en manglende offload som et normalt planlægningsscenarie, ikke som en undtagelse.

Sikker overvågning af DPDK under drift

Driften af en DPDK-datavej kræver målinger, der tager højde for både pakkehåndtering og ressourcer. Registrer som minimum behandlede, kasserede og fejlbehæftede pakker samt applikationsspecifikke værdier for behandlingshastigheder, mempool-reserver og Latensfordeling i stedet for blot et gennemsnitsværdi. Hvilke yderligere port-, kø- eller driver-tællere der er tilgængelige, afhænger af den konkrete PMD, NIC’en og applikationen og skal kontrolleres for den anvendte kombination.

Polling er en bevidst konflikt mellem mål. En lcore afprøver løbende sin Rx-kø, så pakker kan behandles uden den normale interrupt-vej. Selv når der er lidt eller ingen trafik, forbliver poll-sløjfen alligevel aktiv. Planlæg derfor ud over datavejs-lcore-CPU'ens kapacitet også plads til styringslogik, telemetri og operativsystemet. Den supplerende EAL-dokumentation henviser til DPDK 25.07; versionafhængige funktioner skal kontrolleres i den installerede version.

For årsagsanalysen er en tidsmæssig sammenhæng vigtig. Hvis pakketab opstår samtidig med fejltællere, faldende mempool-reserver eller en overbelastet datavej-lcore, er dette i første omgang kontrollerbare indikationer og endnu ikke et entydigt bevis på årsagen. Ujævne svartider kan blandt andet hænge sammen med NUMA-fjerntliggende hukommelse, konkurrerende opgaver eller pipeline-overførsler. Sammenlign sådanne hypoteser med kerneallokering, køfordeling og måleværdier fra det samme tidsvindue.

Hurtig registrering ved grænsefladen er ikke det samme som fuldstændig og vedvarende tabsfri pakkerejstring. Til flowstatistikker eller header-analyse kan få metadata være tilstrækkeligt. Skal hver enkelt pakke gemmes, begrænser desuden lagerbåndbredde, buffervolumen, skrivehastighed og det valgte lagringsmedium opbygningen. Databeskyttelse og opbevaringsregler er i denne sammenhæng uafhængige krav, som netværksgennemstrømningen ikke løser.

Planlæg virtuelle maskiner og containere som en separat integrationsopgave. Afklar for den konkrete platform, hvordan enhedsadgang, lagerplads, CPU-tildeling og nødvendige rettigheder stilles til rådighed. Kontroller denne kombination med den anvendte PMD i stedet for blot at overtage eksempelparametrene uden videre. Den linkede Linux-vejledning er aktuelt på udviklingsstand 26.11.0-rc1; for en produktiv installation er dokumentationen for den faktisk installerede udgave afgørende.

Systematisk kontrol af typiske fejlmønstre

Fejlfinding bør først skelne mellem observerbare symptomer og mulige årsager. Du bør ikke ændre driverbinding, kø-nummer og hukommelsesparametre på samme tid, da årsagen til fejlen så ikke længere kan spores. Ikke-destruktive tællere, indblik i konfigurationen og en sammenligning mellem den berørte og den ikke-berørte kø giver som regel de mest pålidelige ledetråde, inden der gribes ind.

Hvis køen opfører sig usædvanligt, skal du kontrollere køens ejer og mempoolens NUMA-node. I Run-to-completion-modellen håndterer den tildelte lcore modtagelse, behandling og afsendelse; en pipeline videresender pakker til andre kerner. Del dog ikke Rx-køen mellem lcores. Samtidig adgang til en Tx-kø er kun mulig, hvis der er rapporteret RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-funktionen er kun tiltænkt som en undtagelse. En blokering, man selv har tilføjet, gør, at deling af køer ikke er den anbefalede skaleringsstrategi.

Hvis der mangler hardware-offloads, er det rigtige spørgsmål ikke blot, hvilken indstilling der er valgt, men hvilke funktioner enheden og PMD’en rent faktisk stiller til rådighed. Et program kan planlægge en ønsket funktion, uden at den er tilgængelig for denne model. Sammenlign understøttelsen af det konkrete NIC med de funktioner, der rapporteres ved kørselstid, før du gør datavejen afhængig af denne offload.

Resultaterne fra testpmd skal betragtes som en baseline eller en funktionstest, ikke som et bevis på ydeevnen i den senere anvendelse. I io-forwarding-tilstand videresendes pakker uændret, uden at deres indhold analyseres med henblik på faglig behandling. Denne tilstand tager ikke højde for parsere, flow-tabeller, NAT, kryptering og protokolstatus. Den linkede, ikke-versionerede dokumentation hører til 26.11.0-rc1; kontroller adfærden i manualen til den installerede udgave. Noter videresendelsesmodus, pakkestørrelse, antal Rx-/Tx-køer og videresendelseskerner, og gentag sammenligningen med den reelle behandlingslogik.

Implementering, versionsvedligeholdelse og beslutning om ibrugtagning

Start med en isoleret test og en dokumenteret lastprofil: Pakkestørrelser, spidsbelastning, antal strømme og nødvendige behandlingstrin. Kontroller det konkrete NIC samt den passende Poll Mode-driver og de nødvendige funktioner ved hjælp af den officielle hardwareoversigt og drivermatrix. En opført producent alene bekræfter hverken hvert kort eller alle offloads. Test derefter med reel applikationslogik, ikke udelukkende med et videresendelseseksempel.

Notér DPDK-version, firmware, drivere, kerne og konfiguration for hvert forsøg. Læs release-noterne for den nøjagtigt påtænkte release-tag inden en opdatering, og dokumenter, hvilke ændringer der er relevante for din egen datavej. Release-noter fra forskellige versioner er ikke en erstatning for denne tilknytning, da funktioner og begrænsninger kan ændre sig mellem de forskellige udgivelser.

Et konkret punkt fra release notes til DPDK 26.07 er den ændrede flush-/refill-algoritme for mempool-cachen: Dens effektive størrelse svarer nu til den konfigurerede størrelse; tidligere var den 50 procent større. Kun hvis hver lcore udelukkende henter objekter fra eller udelukkende returnerer objekter til en mempool, anbefaler release notes at fordoble den konfigurerede cache-størrelse for at undgå en mulig fordobling af cache-miss-raten. Dette gælder f.eks. pipelines med adskilte Rx- og Tx-lcores, ikke generelt »run-to-completion«. Ændringen vedrører udgave 26.07; den linkede historiske udgivelsesside findes nu i dokumentationen til 26.11.0-rc1.

Start med et begrænset pilotprojekt og faste afbrydelseskriterier. Sammenlign gennemstrømning, høje latenspercentiler, pakketab og CPU-behov under de samme betingelser som den hidtidige drift. Kontroller overvågning, genstarter og tilbagevenden til den tidligere konfiguration. Tag driftsomkostningerne i betragtning; der kan ikke udledes en generel gennemstrømningsgaranti heraf.

Det er især en god idé at vælge DPDK, hvis den målte nytteværdi retfærdiggør den ekstra vedligeholdelsesindsats. Artiklen supplerer klassificeringen af den omgivende systemplatform Linux-kernen i hosting-drift Planlægningen. Behold også den eksisterende netværkssti som sammenligningsgrundlag i testen for almindelige hosting-tjenester.