DPDK: Jak prawidłowo zaplanować przetwarzanie pakietów w przestrzeni użytkownika

Podstawowa zasada DPDK i prawidłowa klasyfikacja

DPDK jest frameworkiem przeznaczonym dla aplikacji, które muszą przetwarzać pakiety sieciowe w przestrzeni użytkownika przy jak najmniejszym obciążeniu. Zamiast korzystać ze standardowej ścieżki poprzez stos sieciowy jądra, gniazda (sockets) i związane z nimi struktury pakietów, aplikacja może bezpośrednio wykorzystywać wybrane karty sieciowe do tworzenia własnej ścieżki danych. Ma to na celu przede wszystkim zapewnienie wysokiej częstotliwości pakietów, niskich opóźnień oraz łatwego do zaplanowania przetwarzania wielu małych pakietów.

Sformułowanie „bez ograniczeń jądra“ jest tu uproszczeniem. Jądro systemu Linux nadal odpowiada za system operacyjny, zarządzanie pamięcią, procesy, bezpieczeństwo oraz liczne zadania administracyjne. DPDK nie zastępuje również ograniczeń karty sieciowej, ani ograniczeń PCIe, przepustowości pamięci czy procesora. W przypadku interfejsów przypisanych omija przede wszystkim standardową ścieżkę danych jądra i przenosi obsługę pakietów do wyspecjalizowanej aplikacji.

W standardowej ścieżce sieciowej systemu Linux współdziałają sterowniki sieciowe, NAPI, system zarządzania pakietami oraz warstwa gniazd. Ścieżka ta nie opiera się wyłącznie na przerwaniach. DPDK-Tryb ankiety – sterownik pobiera dane z kolejek odbiorczych bezpośrednio z przestrzeni użytkownika. Aplikacja odbiera pakiety w grupach, sprawdza je lub modyfikuje, a następnie przekazuje do kolejki wysyłkowej lub do kolejnego etapu przetwarzania.

Nie jest to ogólne dostrajanie jądra i w przypadku zwykłej aplikacji internetowej z niewielką liczbą połączeń TCP zazwyczaj nie jest to pierwszy krok, jaki należy podjąć. Dopiero gdy sama ścieżka przesyłania pakietów jest wyraźnie ograniczona, na przykład w przypadku rozładowywania obciążenia na poziomie L4, filtrowania lub punktów końcowych tuneli, potencjalna korzyść uzasadnia dodatkowy nakład operacyjny. Właściwości zależne od wersji należy sprawdzić w oparciu o dokumentację konkretnego tagu wydania; nie należy przy tym utożsamiać wersji Release Candidate z wersją używaną w środowisku produkcyjnym.

Jak działa ścieżka pakietów w przestrzeni użytkownika

Na wejściu aplikacja konfiguruje jedną lub więcej kolejek Rx karty sieciowej. Przypisany rdzeń wykonawczy w pętli sprawdza kolejkę i otrzymuje serię dostępnych pakietów. Te Przetwarzanie seryjne zmniejsza liczbę wywołań funkcji i nakład administracyjny na każdy pakiet. Po klasyfikacji, przekazaniu lub modyfikacji aplikacja umieszcza pakiety zbiorczo w kolejce Tx.

Metoda pollingowa pozwala uniknąć wielu zmian przerwań w intensywnie obciążonej ścieżce danych i sprawia, że praca rdzenia staje się bardziej przewidywalna. Ceną za to jest ciągła aktywność procesora: nawet gdy kolejka jest pusta, rdzeń lcore nadal sprawdza, czy pojawiły się nowe pakiety. Dlatego model ten lepiej sprawdza się w przypadku stałego, wysokiego obciążenia niż w przypadku interfejsów o rzadkim lub silnie zmiennym ruchu.

Dane pakietu i metadane znajdują się w rte_mbuf-obiektów. Pochodzą one z wcześniej utworzonej puli pamięci (mempool) i zawierają na przykład długość pakietu, port wejściowy, informacje dotyczące odciążania oraz, w razie potrzeby, skrót RSS. Wcześniej zarezerwowane pule, stałe przyporządkowanie do rdzenia kolejki oraz krótkie ścieżki przetwarzania sprzyjają Lokalizacja pamięci podręcznej i unikamy niepotrzebnych wspólnych struktur danych.

Zero Copy nie jest jednak automatyczną właściwością DPDK. To, czy i gdzie dane są kopiowane, zależy od karty sieciowej, sterownika, funkcji odciążających oraz logiki aplikacji. Duże lub segmentowane ramki mogą składać się z kilku połączonych mbufów; ma to znaczenie na przykład w przypadku ramek typu jumbo. Każdy, kto przekształca dane pakietów, łączy je lub przesyła między niekompatybilnymi buforami, musi uwzględnić ewentualne operacje przenoszenia danych w swojej ścieżce danych.

Architektura, zasoby i sztywne ograniczenia

Warstwa abstrakcji środowiska, w skrócie EAL, inicjuje DPDK i zapewnia między innymi rezerwację pamięci, dostęp do urządzeń, liczniki czasu oraz przypisanie rdzeni logicznych. Na tej podstawie aplikacja konfiguruje kolejki Ethernet, pule pamięci oraz ich przetwarzanie. Lcore to w tym kontekście jądro logiczne zaplanowane dla DPDK, a nie po prostu dowolnie przemieszczający się wątek aplikacji. Te podstawowe właściwości EAL są tutaj poparte dokumentacją DPDK 25.07; szczegóły zależne od wersji należy dodatkowo sprawdzić dla używanego tagu wydania.

Aby zapewnić prostą ścieżkę przepływu danych, jeden rdzeń często przetwarza pakiet w całości: od odbioru, przez podjęcie decyzji, aż po wysłanie. Ten model „run-to-completion” pozwala uniknąć przekazywania danych między rdzeniami. Natomiast potok dzieli na przykład parsowanie, wyszukiwanie przepływu i przekazywanie na poszczególne etapy. Pozwala to uporządkować zakresy odpowiedzialności, ale powoduje pojawienie się pętli, konieczność synchronizacji oraz potencjalnie gorszą lokalność pamięci między etapami.

Podczas planowania należy również uwzględnić architekturę NUMA. Kolejka, lcore i pule pakietów powinny w miarę możliwości znajdować się w tym samym węźle NUMA, aby ścieżka danych nie musiała regularnie uzyskiwać dostępu do pamięci innego gniazda procesora. Osiągalna wydajność zależy ponadto od funkcji kart sieciowych (NIC), połączenia PCIe, przepustowości pamięci, częstotliwości taktowania procesora, rozmiaru pakietów oraz złożoności każdej decyzji dotyczącej pakietów.

Moduł równoważenia obciążenia L4 może szybko analizować informacje o adresach IP i portach za pomocą DPDK, przyporządkowywać przepływy i przekazywać pakiety. Nie powoduje to jednak automatycznego przyspieszenia terminacji TLS, skomplikowanych stanów NAT, rejestrowania, kontroli stanu ani powolnych serwerów zaplecza. Podobnie płaszczyzna sterowania wymaga dostępnego czasu procesora do konfiguracji, telemetrii i obsługi błędów. DPDK przyspiesza zatem ściśle określony ścieżkę danych, a niekoniecznie całą usługę.

Również rozmiar i żywotność buforów pakietów stanowią część architektury. Pule pamięci ograniczają liczbę buforów dostępnych jednocześnie, podczas gdy aplikacja musi prawidłowo zarządzać zmianami własności. Zbyt małe pule mogą się wyczerpać pod obciążeniem; zbyt duże rezerwacje zajmują pamięć. Optymalny rozmiar wynika z kolejek, wielkości impulsów, ścieżki pakietów i przewidywanych szczytów obciążenia, a nie z uniwersalnych wytycznych.

Sprawdzić warunki przed użyciem DPDK

Wdrożenie DPDK można zaplanować dopiero wtedy, gdy sprzęt, pamięć i przypisanie procesora są ze sobą zgodne. Sama instalacja nie zapewnia wydajnej ścieżki danych: moduł PMD musi obsługiwać konkretny model karty sieciowej, a zasoby muszą dać się zarezerwować dla aplikacji. Poniższa analiza odróżnia minimalne wymagania techniczne od założeń, które mają zastosowanie wyłącznie do faktycznie używanego urządzenia.

Strony typu „hugepage” są standardowym rozwiązaniem w przypadku rozległych pul pakietów, ale nie stanowią bezwzględnego warunku dla każdej aplikacji DPDK. EAL obsługuje również opcję –no-huge. Ten tryb specjalny nie jest równoważny standardowej rekomendacji: przed rozpoczęciem fazy pilotażowej należy sprawdzić jego przydatność, zarządzanie pamięcią oraz ograniczenia sterowników. Podstawy dotyczące systemu i EAL opisane w niniejszym dokumencie odnoszą się do DPDK 25.07; należy dodatkowo porównać te opcje z faktycznie zainstalowaną wersją.

Szczególnie krytyczna jest Powiązanie z urządzeniem. Wiele modułów PMD wymaga, aby dana karta sieciowa została odłączona od standardowego sterownika jądra i podłączona na przykład do vfio-pci zostaje przypisany. Interfejs nie jest wówczas już standardowo dostępny dla zwykłego stosu sieciowego systemu Linux. Konkretny sposób postępowania musi jednak być dostosowany do danego PMD i nie można go stosować ogólnie do każdej obsługiwanej karty sieciowej.

Ważnym wyjątkiem są rozgałęzione moduły PMD. Dokumentacja sterownika wskazuje, że takie moduły PMD nie powinny być odłączane przez odpowiedni sterownik jądra. Sterownik jądra może pozostać podłączony, podczas gdy ścieżka danych w przestrzeni użytkownika korzysta z określonych zasobów. Dokumentacja, do której prowadzi link, nie jest opatrzona numerem wersji i odzwierciedla stan rozwoju z dnia 26.11.0-rc1; nie stanowi ona instrukcji powiązanej z konkretną wersją 26.07. Należy sprawdzić obsługę urządzeń i dostępne narzędzia jądra w podręczniku konkretnego, używanego urządzenia PMD.

Przed każdą zmianą poniższe zapytanie o stan dostarcza wykaz urządzeń PCI wraz z ich aktualnymi powiązaniami ze sterownikami. Samo w sobie nie zmienia ono żadnych powiązań. Należy je uruchomić w systemie docelowym, podając ścieżkę odpowiadającą zainstalowanej strukturze źródłowej lub narzędziowej DPDK.

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

Dostęp do zarządzania planem i ścieżka danych produkcyjnych powinny być oddzielone, nawet jeśli wybrany PMD nie zastępuje sterownika jądra. Dostępność SSH lub konsoli nie może zależeć od interfejsu, którego przypisanie lub podział ruchu ulegają zmianie w trybie pilotażowym. Oddzielny interfejs zarządzania, dostęp poza pasmem lub wcześniej sprawdzona lokalna ścieżka awaryjna ograniczają ryzyko nieprawidłowej konfiguracji.

Porównanie DPDK, AF_XDP i Kernelstack

Wybór ścieżki transmisji danych nie jest kwestią hierarchii, lecz decyzją operacyjną. Stos jądra Linuksa, AF_XDP i DPDK w różny sposób wpływają na nakład pracy, dostęp do urządzeń i zużycie procesora. Wybór odpowiedniej opcji zależy od tego, czy ograniczeniem w ścieżce sieciowej jest faktycznie przepustowość pakietów, czy opóźnienie – a może wąskim gardłem są aplikacja, szyfrowanie i komponenty zaplecza.

AF_XDP to opcja pośrednia dla zespołów, które chcą przetwarzać pakiety na wczesnym etapie, a jednocześnie pozostać blisko modelu sieciowego systemu Linux. Jądro opisuje tryb kopiowania oraz tryb Zero Copy, który wymaga obsługi ze strony sterownika. Jeśli tryb Zero Copy jest wyraźnie wymagany, utworzenie gniazda może się nie powieść, jeśli sterownik nie oferuje tej funkcji. W klasyfikacji warstwy XDP pomocny jest artykuł XDP i eXpress Data Path.

Z kolei DPDK wykorzystuje sterowniki typu „poll mode” i przetwarza kolejki bezpośrednio z poziomu aplikacji. Pozwala to ominąć elementy związane z gniazdami i przerwaniami w ścieżce danych DPDK, wymaga jednak przejęcia odpowiedzialności za pamięć, kolejki i przypisanie jądra. Zero Copy Nie jest to ani ogólna obietnica wydajności, ani automatyczna cecha dowolnej ścieżki DPDK; liczba kopii zależy od aplikacji, operacji offload oraz operacji przenoszenia danych do pamięci.

Wybierz stos jądra, jeśli routing, zapora sieciowa, obserwowalność i łatwość obsługi są ważniejsze niż wyspecjalizowana ścieżka pakietów. Rozważ zastosowanie AF_XDP w przypadku ukierunkowanego przyspieszenia z wykorzystaniem połączenia z jądrem. DPDK opłaca się dopiero w przypadku rzeczywistej potrzeby zapewnienia wysokiej przepustowości pakietów lub stałego opóźnienia, istniejącej obsługi kart sieciowych oraz zespołu, który jest w stanie na stałe przejąć dodatkową odpowiedzialność za eksploatację.

Rozsądne planowanie kolejek, przypisywania procesorów i architektury NUMA

Wytrzymała Przypisanie do kolejki Zaczyna się od bliskości między kartą sieciową (NIC), procesorem (CPU) a pamięcią. EAL obsługuje wybór rdzeni logicznych, rezerwację pamięci oraz przypisywanie urządzeń. W przypadku prostej ścieżki danych zazwyczaj sensowne jest stałe przypisanie kolejki Rx do jednego jądra logicznego (lcore), utworzenie odpowiedniej puli pamięci (mempool) w lokalnym węźle NUMA, a następnie przekazanie przetwarzania do odpowiedniej kolejki Tx. Te podstawowe informacje dotyczące EAL są poparte dokumentacją DPDK 25.07 i należy je zweryfikować pod kątem opcji zależnych od wersji, odnosząc się do używanego tagu wydania.

Przykładem hosta z dwoma węzłami NUMA, niezwiązanym z konkretnym produktem, mogłaby być następująca sytuacja: karta sieciowa w węźle 0 otrzymuje dwie kolejki odbiorcze (Rx); każdy z procesorów lcore w węźle 0 przetwarza jedną kolejkę w całości. Bufory pakietów również znajdują się w węźle 0. Kolejne jądro, które nie wykonuje operacji odpytywania, pozostaje wolne do zadań administracyjnych, podczas gdy węzeł 1 jest przeznaczony dla innych usług lub wyraźnie oddzielonych ścieżek danych.

• Ścieżka danych: dla każdej kolejki stałe przypisanie lcore, lokalne pule pamięci oraz jasno nazwane pary Rx/Tx.
• Administracja: Należy zapewnić wolną moc obliczeniową procesora dla telemetrii, logiki sterującej, zdarzeń i usług systemu operacyjnego.
• Rezerwa: Należy uwzględnić rezerwę mocy na potrzeby szczytowego obciążenia, diagnostyki usterek i planowanych rozbudów, zamiast trwale wykorzystywać wszystkie rdzenie.

Nie należy dzielić kolejki Rx między wiele rdzeni lcore. W przewodniku PMD odradza się dzielenie kolejek Rx i Tx, ponieważ niezbędne do tego globalne blokady mogą znacznie obniżyć wydajność. Jednoczesny dostęp wielu rdzeni do jednej kolejki Tx jest przewidziany jako udokumentowany wyjątek tylko wtedy, gdy sterownik posiada możliwość RTE_ETH_TX_OFFLOAD_MT_LOCKFREE zgłasza. Sprawdź tę zdolność dla konkretnej kombinacji karty sieciowej (NIC) i modułu PMD; nie wyznaczaj jej ani na podstawie prędkości portu, ani na podstawie ogólnego przełącznika odciążania.

Potok z oddzielnymi etapami analizy, klasyfikacji i wysyłania może zapewnić większą przejrzystość podziału obowiązków. Udokumentowane podejście oparte na potoku przekazuje pakiety do kolejnych rdzeni za pośrednictwem pierścieni; powoduje to dodatkowe operacje dostępu do pamięci i przekazywania danych. W przypadku prostych filtrów lub przekazywania na poziomie L4 często łatwiej jest zaplanować realizację do końca dla każdej kolejki. Stosowanie wielu etapów powinno mieć miejsce tylko wtedy, gdy podział pracy uzasadnia dodatkowy nakład w konkretnym profilu obciążenia.

Również Odciążanie sprzętowe nie należy uwzględniać ich w planowaniu. To, jakie funkcje sum kontrolnych, segmentacji, RSS lub przepływu są dostępne, zależy od możliwości konkretnego urządzenia Ethernetowego i jego modułu PMD. Należy je sprawdzić przed rozpoczęciem projektowania i traktować brak możliwości odciążenia jako normalny przypadek projektowy, a nie jako wyjątek.

Bezpieczne monitorowanie pracy DPDK

Do obsługi ścieżki danych DPDK potrzebne są wskaźniki, które uwzględniają zarówno przetwarzanie pakietów, jak i zasoby. Należy rejestrować co najmniej liczbę przetworzonych, odrzuconych i uszkodzonych pakietów, a także wartości specyficzne dla aplikacji dotyczące szybkości przetwarzania, rezerw pamięci typu mempool oraz Rozkład opóźnień zamiast jednej wartości średniej. To, jakie dodatkowe liczniki portów, kolejek lub sterowników są dostępne, zależy od konkretnego modułu PMD, karty sieciowej (NIC) i aplikacji i należy to sprawdzić dla danej kombinacji.

Polling stanowi świadomy konflikt celów. Lcore na bieżąco sprawdza swoją kolejkę Rx, aby pakiety mogły być przetwarzane bez korzystania ze standardowej ścieżki przerwań. Jednak nawet przy niewielkim natężeniu ruchu lub jego braku pętla pollingowa pozostaje aktywna. W związku z tym oprócz lcore’ów ścieżki danych należy zaplanować moc obliczeniową procesora na potrzeby logiki sterującej, telemetrii i systemu operacyjnego. Dodatkowa dokumentacja EAL odnosi się do wersji DPDK 25.07; funkcje zależne od wersji należy sprawdzić w zainstalowanej wersji.

W analizie przyczyn istotna jest korelacja czasowa. Jeśli utrata pakietów występuje równocześnie z wzrostem liczby błędów, spadkiem rezerw w mempoolu lub przeciążeniem ścieżki danych lcore, są to na razie wskazówki, które można zweryfikować, ale nie stanowią jeszcze jednoznacznego dowodu na przyczynę. Wahania czasów odpowiedzi mogą wynikać między innymi z pamięci oddalonej od NUMA, konkurujących zadań lub przekazów w potoku. Należy porównać takie hipotezy z przypisaniem rdzeni, rozkładem kolejek oraz wartościami pomiarowymi z tego samego przedziału czasowego.

Szybkie rejestrowanie na interfejsie nie oznacza pełnego, trwałego i bezstratnego rejestrowania pakietów. Do statystyk przepływu lub analizy nagłówków może wystarczyć niewielka ilość metadanych. Jeśli każdy pakiet ma zostać zapisany, dodatkowymi ograniczeniami dla struktury systemu są przepustowość pamięci, pojemność bufora, przepustowość zapisu oraz wybrany nośnik pamięci. Ochrona danych i zasady przechowywania stanowią w tym kontekście niezależne wymagania, których nie rozwiązuje przepustowość sieci.

Zaplanuj maszyny wirtualne i kontenery jako odrębne zadanie integracyjne. Sprawdź dla konkretnej platformy, w jaki sposób zapewniany jest dostęp do urządzeń, pamięci, przydział procesora oraz wymagane uprawnienia. Sprawdź tę konfigurację przy użyciu stosowanego modułu PMD, zamiast bezkrytycznie przejmować przykładowe parametry. Podany w linku przewodnik dotyczący systemu Linux odnosi się obecnie do wersji rozwojowej 26.11.0-rc1; w przypadku wdrożenia produkcyjnego decydująca jest dokumentacja faktycznie zainstalowanej wersji.

Systematyczne sprawdzanie typowych usterek

Podczas diagnostyki błędów należy najpierw oddzielić obserwowalne objawy od potencjalnych przyczyn. Nie należy zmieniać jednocześnie powiązania sterownika, liczby kolejek i parametrów pamięci, ponieważ uniemożliwi to ustalenie przyczyny problemu. Liczniki nieniszczące, wgląd w konfigurację oraz porównanie kolejki, w której wystąpił błąd, z kolejką, w której błąd nie wystąpił, dostarczają zazwyczaj bardziej wiarygodnych wskazówek przed podjęciem jakichkolwiek działań.

W przypadku nietypowego zachowania kolejki sprawdź właściciela kolejki oraz węzeł NUMA, do którego należy pula pamięci. W modelu „run-to-completion” przypisany rdzeń lcore zajmuje się odbiorem, przetwarzaniem i wysyłaniem; potok przekazuje pakiety do kolejnych rdzeni. Nie należy jednak dzielić kolejki Rx między rdzeniami lcore. Jednoczesny dostęp do kolejki Tx jest możliwy tylko w przypadku zgłoszonego RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Ta funkcja została przewidziana jako wyjątek. Samodzielnie ustawiona blokada sprawia, że współdzielenie kolejki nie jest zalecaną strategią skalowania.

W przypadku braku funkcji odciążania sprzętowego właściwym pytaniem nie jest tylko to, który przełącznik został ustawiony, ale jakie możliwości faktycznie zapewniają urządzenie i PMD. Aplikacja może zaplanować żądaną funkcję, nawet jeśli nie jest ona dostępna dla danego modelu. Przed uzależnieniem ścieżki danych od tego odciążenia należy porównać obsługę konkretnej karty sieciowej z możliwościami zgłoszonymi w czasie wykonywania.

Wyniki testpmd należy traktować jako punkt odniesienia lub test funkcjonalny, a nie jako potwierdzenie wydajności przyszłego zastosowania. W trybie io-forwarding pakiety są przekazywane bez zmian, bez analizowania ich zawartości pod kątem merytorycznego przetwarzania. Tryb ten nie uwzględnia parserów, tabel przepływu, NAT, szyfrowania ani stanu protokołu. Dokumentacja, do której prowadzi link, dotyczy wersji 26.11.0-rc1; sprawdź zachowanie w podręczniku zainstalowanej wersji. Zapisz tryb przekazywania, rozmiar pakietu, liczbę kolejek Rx/Tx oraz liczbę rdzeni przekazywania i powtórz porównanie z rzeczywistą logiką przetwarzania.

Wdrożenie, aktualizacja wersji i decyzja o uruchomieniu

Zacznij od testu w izolacji i udokumentowanego profil obciążenia: rozmiary pakietów, obciążenie szczytowe, liczba strumieni oraz wymagane etapy przetwarzania. Sprawdź konkretną kartę sieciową wraz z odpowiednim sterownikiem trybu Poll Mode i wymaganymi funkcjami, korzystając z oficjalnego przeglądu sprzętu i tabeli sterowników. Sam fakt umieszczenia producenta na liście nie potwierdza ani dostępności każdej karty, ani wszystkich funkcji odciążających. Następnie przeprowadź testy z wykorzystaniem rzeczywistej logiki aplikacji, a nie wyłącznie na przykładzie przekierowania.

Zapisz wersję DPDK, oprogramowanie układowe, sterowniki, jądro i konfigurację dla każdego testu. Przed aktualizacją przeczytaj informacje o wydaniu dotyczące dokładnie wybranego tagu wydania i udokumentuj, które zmiany mają znaczenie dla Twojej ścieżki danych. Informacje o wydaniu dotyczące różnych wersji nie zastępują tego przyporządkowania, ponieważ funkcje i ograniczenia mogą się zmieniać między poszczególnymi wydaniami.

Jednym z konkretnych punktów do sprawdzenia, wymienionych w informacjach o wydaniu DPDK 26.07, jest zmieniony algorytm opróżniania i uzupełniania pamięci podręcznej mempool: jej efektywny rozmiar odpowiada od tej pory rozmiarowi skonfigurowanemu; wcześniej był on o 50 procent większy. Tylko w przypadku, gdy każdy rdzeń lcore pobiera z pamięci Mempool wyłącznie obiekty lub wyłącznie je zwraca, w informacjach o wydaniu zaleca się podwojenie skonfigurowanego rozmiaru pamięci podręcznej, aby uniknąć ewentualnego podwojenia wskaźnika braku trafień w pamięci podręcznej. Dotyczy to na przykład potoków z oddzielnymi rdzeniami Rx i Tx, a nie ogólnie trybu „run-to-completion”. Zmiana dotyczy wersji 26.07; podana w linku strona z historią wydań znajduje się obecnie w dokumentacji do wersji 26.11.0-rc1.

Zacznij od ograniczonego projektu pilotażowego z jasno określonymi kryteriami przerwania. Porównaj przepustowość, wysokie percentyle opóźnień, utratę pakietów oraz zapotrzebowanie na moc procesora w takich samych warunkach z dotychczasowym trybem pracy. Sprawdź mechanizmy monitorowania, ponowne uruchamianie oraz powrót do poprzedniej konfiguracji. Weź pod uwagę nakłady operacyjne; nie można na tej podstawie wywnioskować ogólnej gwarancji przepustowości.

Wdrożenie DPDK opłaca się przede wszystkim wtedy, gdy zmierzone korzyści uzasadniają dodatkowy nakład pracy związany z utrzymaniem. Artykuł ten uzupełnia informacje dotyczące klasyfikacji otaczającej platformy systemowej. Jądro systemu Linux w usługach hostingowych Planowanie. W przypadku zwykłych usług hostingowych zachowaj w teście dotychczasową ścieżkę sieciową jako punkt odniesienia.