Karty SmartNIC w hostingu: jak właściwie ocenić przyspieszenie sieciowe

Właściwe wykorzystanie kart SmartNIC w hostingu

Termin SmartNIC nie jest ujednoliconą, znormalizowaną nazwą produktu. Dlatego przy planowaniu hostingu decydujące znaczenie ma nie nazwa, lecz potwierdzona funkcja w ścieżce danych: jakie pakiety, reguły i tunele może przetwarzać karta, jakie zadania pozostają w gestii hosta i jakie oprogramowanie steruje tymi funkcjami? Wysoka prędkość portu nie daje odpowiedzi na te pytania.

Klasyczna karta sieciowa zapewnia przede wszystkim połączenie Ethernet i obsługuje popularne podstawowe funkcje odciążające, takie jak sumy kontrolne czy segmentacja. Jedna SmartNIC rozszerza te ramy o specjalistyczne lub programowalne funkcje ścieżek danych. Mogą one obejmować reguły przepływu, funkcje przełączania wirtualnego, SR-IOV, przetwarzanie tuneli lub zadania kryptograficzne. O tym, czy funkcje te są dostępne, decydują jednak łącznie model, oprogramowanie układowe, sterowniki oraz integracja z platformą.

A DPU ma zazwyczaj bardziej rozbudowaną architekturę: oprócz układu ASIC sieciowego dysponuje własnymi zasobami obliczeniowymi i może obsługiwać oddzielną ścieżkę danych infrastruktury. Firma NVIDIA opisuje dla BlueField tryb DPU, w którym zintegrowany system ARM kontroluje zasoby karty sieciowej (NIC) oraz ścieżkę danych, a także tryb NIC, w którym karta zachowuje się wobec zewnętrznego hosta jak adapter. W ten sposób, w zależności od trybu pracy, powstaje również odrębna strefa zarządzania i zaufania.

Ta klasyfikacja ma praktyczne konsekwencje dla zaopatrzenia i eksploatacji. Karta z własną logiką obliczeniową niekoniecznie jest lepszym wyborem, jeśli wymagane są jedynie proste, podstawowe operacje odciążające. Z drugiej strony, zewnętrzna ścieżka infrastrukturalna może być sensownym rozwiązaniem w celu zapewnienia separacji klientów lub funkcji bezpieczeństwa, wymaga jednak wówczas konserwacji oprogramowania układowego, koncepcji dostępu, monitorowania oraz procesów odzyskiwania danych dla dodatkowych komponentów.

Nawet port 100 GbE lub szybszy nie zapewnia przyspieszenia działania reguł zapory, sieci nakładkowych ani szyfrowania. Decydujące znaczenie mają rozmiar pakietu, liczba równoległych przepływów, zakres reguł oraz to, czy wymagane działania można faktycznie zrealizować w sprzęcie. Dopiero gdy procesor serwera w sposób wyraźny stanowi ograniczenie w ścieżce danych sieciowych, lista funkcji przekłada się na potencjalny wzrost przepustowości.

Jak odciążanie sprzętowe zmienia ścieżkę przepływu danych

Bez dalszego odciążania pakiet trafia najpierw do fizycznej karty sieciowej, a następnie jest przetwarzany przez host. W zależności od architektury przechodzi on przez stos sieciowy jądra, zaporę sieciową, most lub przełącznik wirtualny, routing oraz, w razie potrzeby, kapsułkowanie dla sieci nakładkowej. Dopiero potem dociera do maszyny wirtualnej, kontenera lub innego portu fizycznego. Każdy etap może powodować zużycie czasu procesora i tworzenie kolejek.

Ścieżka ta ma szczególne znaczenie w przypadku wielu małych pakietów, licznych połączeń krótkotrwałych lub rozbudowanych zasad dotyczących klientów. Obciążenie serwera wynika nie tylko z ilości przesyłanych danych, ale także z wielokrotnego przetwarzania poszczególnych pakietów i strumieni. Dlatego też przyspieszenie sieci nie jest to ogólna cecha serwera, lecz celowe odciążenie konkretnie zidentyfikowanej ścieżki danych.

Na stronie Odciążanie sprzętowe Komponenty sterujące mogą przekazywać dopuszczalne reguły przekazywania i filtrowania do sprzętowej ścieżki danych. Model switchdev systemu Linux opisuje w tym kontekście przeniesienie ścieżki przekazywania danych z jądra do urządzenia przełączającego. To, które reguły zostaną faktycznie przejęte, zależy od konkretnej karty, jej sterownika oraz nadrzędnej integracji sieciowej.

Dokumentacja OVS w gałęzi rozwojowej 4.0.90 wyraźnie określa osobny rozdział poświęcony odciążaniu sprzętowemu przepływu (Flow Hardware Offload) jako eksperymentalny. Właśnie dla tej konfiguracji OVS z DPDK rozróżnia się pełne odciążanie dopasowań i akcji oraz częściowe odciążanie, w którym odciążane są wyłącznie dopasowania. Opis ten nie stanowi stabilnego, ogólnie obowiązującego potwierdzenia zgodności z innymi wersjami OVS, kartami sieciowymi (NIC) lub platformami.

W praktyce każda informacja o odciążeniu musi zatem określać konkretną ścieżkę danych: wersję używanego oprogramowania, sterowniki, oprogramowanie układowe, pola dopasowania oraz działania. Włączony przełącznik nie świadczy ani o tym, że odpowiednie przepływy są odciążane, ani o tym, że wymogi bezpieczeństwa i semantyki sieciowej są nadal spełniane. W przypadku filtrowania VLAN narzędzie switchdev wymaga na przykład, aby sprzęt przestrzegał reguł mostkowania VLAN i odrzucał niedozwolone identyfikatory VLAN. Offload jest zatem techniczną realizacją istniejących reguł, a nie obejściem ich.

Gdzie warto stosować karty SmartNIC w hostingu

Karty SmartNIC sprawdzają się przede wszystkim na platformach wirtualizacyjnych z dużą liczbą maszyn wirtualnych i powtarzającymi się decyzjami dotyczącymi przekierowania ruchu. Technologia SR-IOV pozwala przypisać maszynie wirtualnej funkcję wirtualną; w architekturze switchdev interfejsy reprezentacyjne odwzorowują funkcje fizyczne lub wirtualne w systemie operacyjnym. Dzięki temu reguły dotyczące ruchu między tymi portami można zaimplementować w sprzęcie. Korzyści zależą jednak od wymaganych funkcji maszyn wirtualnych.

Sieci nakładkowe obsługujące wielu klientów oraz Mikrosegmentacja stanowią kolejny punkt wyjścia. Jeśli wiele sieci klientów wielokrotnie stosuje przypisania VLAN lub sieci nakładkowych, reguły kontroli dostępu i podobne decyzje dotyczące przepływu danych, odpowiednia ścieżka danych sprzętowa może odciążyć procesory hostów. Warunkiem pozostaje jednak, aby liczba reguł, pola dopasowania i akcje były dostępne w wybranej karcie wraz ze sterownikiem, a semantyka zasad została w pełni zachowana.

W przypadku platformy OpenShift Container Platform 4.22 firma Red Hat dokumentuje funkcję odciążania sprzętowego dla węzłów typu bare-metal wyposażonych w kompatybilną kartę SmartNIC i z aktywnym operatorem sieciowym SR-IOV. Obsługiwana jest tam wyłącznie komunikacja typu pod-pod oraz komunikacja typu pod-ClusterIP-Service z zwykłymi podami; aplikacje DPDK nie są kompatybilne z tą funkcją. Korzyść ta ogranicza się ponadto do segmentów komunikacyjnych, w których uczestniczące węzły wykorzystują kompatybilne karty SmartNIC.

W przypadku szyfrowanych sieci hostów lub lokalnych funkcja odciążania IPsec może przejąć niektóre zadania lub cały proces enkapsulacji, dekapitulacji, szyfrowania oraz ochrony przed odtworzeniem. Firma NVIDIA opisuje w tym zakresie różne rodzaje odciążania, w tym odciążanie kryptograficzne (Crypto-Offload) i pełne odciążanie (Full-Offload). Nie oznacza to jednak, że rozwiązanie to ma uniwersalne zastosowanie: obsługa i ograniczenia wydajności zależą od modelu, oprogramowania układowego oraz stosowanej metody kryptograficznej.

Prosty serwer hostingowy stanowi celowy przykład przeciwny. Jeśli generuje on głównie nieliczne, większe odpowiedzi HTTP i nie wykazuje obciążenia procesora na ścieżce pakietów, można zastosować bardziej wyspecjalizowane sprzęt serwerowy powodują jedynie dodatkowe obciążenie operacyjne. Najpierw należy ustalić, czy przyczyną wąskiego gardła jest aplikacja, baza danych, pamięć masowa czy sieć. Karty SmartNIC nie są opłacalnym rozwiązaniem zastępującym tę diagnostykę.

Porównanie zastosowań pod kątem technicznym

O tym, czy zastosowanie karty SmartNIC ma sens, decyduje nie nominalna prędkość portu, lecz konkretna ścieżka przepływu danych. Jest to szczególnie uzasadnione, gdy wiele powtarzających się reguł, duża liczba przepływów lub funkcje nakładkowe i zabezpieczające stale angażują zasoby procesora hosta. Korzyści pozostają zależne od ścieżki: Sekcja przyspieszona pomaga jedynie połączeniom, które faktycznie przebiegają przy użyciu kompatybilnego sprzętu i obsługiwanych reguł.

W przypadku platform wirtualnych SR-IOV Typowe podejście: funkcje wirtualne są przypisywane do maszyny wirtualnej, podczas gdy interfejsy reprezentujące w systemie operacyjnym odwzorowują porty tych funkcji. Dzięki temu reguły przekierowania między portami wirtualnymi a fizycznymi w architekturze opartej na switchdev mogą zostać zrealizowane sprzętowo. Nie zastępuje to jednak sprawdzenia, czy zachowana jest pożądana separacja klientów oraz model operacyjny.

Kubernetes stanowi przeciwieństwo ogólnej obietnicy przyspieszenia. W przypadku udokumentowanej integracji z OpenShift 4.22 obowiązują określone obsługiwane ścieżki ruchu, kompatybilne węzły SmartNIC oraz wymagania dotyczące obciążeń. Gdy węzeł obsługujący odciążanie komunikuje się ze zwykłym węzłem, ten zwykły węzeł przetwarza swoją część w jądrze, ograniczając w ten sposób całkowitą długość ścieżki. W związku z tym wdrożenie powinno początkowo uwzględniać wyodrębnioną pulę węzłów oraz rzeczywiste ścieżki komunikacyjne.

W przypadku szyfrowanych sieci hostów lub lokalnych terminy te należy stosować z wyjątkową precyzją. Udokumentowane warianty protokołu IPsec, w zależności od platformy, obejmują zakres od „Crypto-Offload” aż po „Full Offload” w odniesieniu do enkapsulacji, dekapitulacji, szyfrowania oraz ochrony przed odtworzeniem. Nie oznacza to jednak ogólnej gwarancji przepustowości: model, oprogramowanie układowe, zastosowane algorytmy oraz ograniczenia związane z produktem decydują o tym, które operacje są faktycznie zlecane na zewnątrz.

Sprawdź zgodność przed wdrożeniem

Proces zakupu należy rozpocząć od obiektywnej oceny aktualnego stanu, a nie od aktywacji opcji odciążania. Należy zarejestrować dokładny model karty wraz z identyfikatorem PCI, wersją oprogramowania układowego, sterownikami i jądrem. Dodatkowo należy znać tryb eSwitch oraz wersję i konfigurację Open vSwitch, OVN, hiperwizora lub platformy Kubernetes, ponieważ sama obsługa karty nie gwarantuje pełnej integracji oprogramowania.

Wymagana semantyka reguł powinna być wcześniej dostępna w postaci opisu ścieżki danych: np. przypisanie do sieci VLAN, IPv4 lub IPv6, TCP lub UDP, typ tunelu, modyfikacja nagłówka, przekazanie lub odrzucenie. Eksperymentalna dokumentacja OVS 4.0.90 wskazuje, że w przypadku konfiguracji DPDK brak działań sprzętowych może prowadzić do częściowego odciążenia. Wynika z tego, że w odniesieniu do każdej innej wersji lub platformy jest to jedynie zlecenie sprawdzenia, a nie gwarancja zakresu jej funkcjonalności.

Matrice platformowe to dowody zgodności związane z wersjami, nie ma tu ogólnych stwierdzeń dotyczących rodziny kart sieciowych. OpenShift 4.22 wymienia konkretne karty sieciowe w ramach integracji odciążania sprzętowego, w tym BlueField-2 w trybie ConnectX-6. Nie można z tego wywnioskować ani obsługi innego oprogramowania układowego, ani innego trybu DPU, ani też odmiennej dystrybucji. Należy zatem oddzielnie udokumentować każdą kombinację sprzętu, oprogramowania układowego, sterownika i wersji platformy.

W przypadku Linux-switchdev kluczowe znaczenie ma również to, aby sprzęt zachowywał semantykę sieci programowej. W przypadku filtrowania VLAN przełącznik odciążający musi na przykład przestrzegać reguł VLAN mostka i odrzucać niedozwolone identyfikatory VLAN. Wymóg ten pokazuje, dlaczego listy funkcji i polityka bezpieczeństwa muszą być sprawdzane łącznie: przyspieszenie nie może powodować odmiennej segmentacji sieci.

Porównanie zalet i wad kart SmartNIC z procesorem i oprogramowaniem

Karta SmartNIC to tylko jedna z wielu opcji, gdy przetwarzanie sieciowe napotyka ograniczenia. Najpierw warto sprawdzić, czy zwiększenie mocy obliczeniowej procesora, odpowiednia liczba kolejek, RSS, rozkład sygnałów IRQ lub dostrojenie jądra nie wystarczą już do usunięcia wąskiego gardła. Aby zapoznać się z klasyfikacją SoftIRQ, kolejek i podziału przerwań, zapraszamy do artykułu na temat Wydajność procesora i przepustowość sieci w usługach hostingowych dalsze podstawy. Bez potwierdzenia wystąpienia wąskiego gardła w sieci dodatkowy specjalistyczny sprzęt pozostaje jedynie hipotezą.

DPDK i AF_XDP mogą skrócić ścieżki oprogramowania na procesorach hosta, ale każde z tych rozwiązań wymaga osobnego projektowania architektury i procesorów. Stwierdzenia dotyczące ciągłego odpytywania nie można ogólnie odnieść do obu tych podejść: W dokumentacji OVS-DPDK dotyczącej opisanej konfiguracji jeden wątek nieustannie odpytuje urządzenia DPDK, zajmując przy tym w całości jedno rdzeń procesora. Przypisanie NUMA, izolacja rdzeni oraz konkretne wersje OVS i DPDK pozostają zatem częścią projektu.

Również klasyczna karta sieciowa serwera może zapewnić wystarczające odciążenie w zakresie sum kontrolnych, segmentacji lub poszczególnych funkcji tunelowania. Taki wybór jest właściwy, jeśli nie są wymagane rozbudowane reguły przełączników wirtualnych, separacja klientów ani sprzętowe ścieżki bezpieczeństwa. Karty SmartNIC stają się opłacalne przede wszystkim wtedy, gdy wymagane funkcje wykraczają poza te podstawowe cechy i mają charakter powtarzalny w dłuższej perspektywie.

Koncepcja pojemności jest prosta, ale istotna: jeśli rdzenie procesora na hoście są obciążone przetwarzaniem pakietów i jeśli reprezentatywną część tych pakietów można całkowicie odciążyć, może powstać wolna pojemność procesora. Zastrzegajmy jednak, że rezerwa ta liczy się jako pojemność użytkowa tylko wtedy, gdy kolejnym wąskim gardłem nie jest aplikacja, pamięć operacyjna, pamięć masowa ani rezerwowy system oprogramowania. Nie wynika ona bezpośrednio z przepustowości łącza ani ceny karty.

Dlatego porównuj alternatywne rozwiązania na podstawie tego samego profilu obciążenia: rozmiary pakietów, szybkość transmisji, liczba reguł, tunele, szyfrowanie oraz przewidywane obciążenie szczytowe. W tym celu należy oddzielić udział procesora w ścieżce danych od pracy aplikacji i sprawdzić, które przepływy danych faktycznie są przetwarzane w sprzęcie. Jeden Ograniczenie wydajności procesora Korzystanie z zapory sieciowej, sieci nakładkowej lub przekierowania wirtualnego stanowi uzasadniony powód do przeprowadzenia oceny; ogólnie wysokie obciążenie systemu nie jest takim powodem.

Widoczność operacji offload podczas pracy

Po wdrożeniu nie wystarczy uznać opcję odciążenia za aktywną. Wiarygodny dowód działania łączy Stan przepływu wraz z licznikami karty, wskaźnikami utraty pakietów i błędów, obciążeniem procesora oraz profilem obciążenia przypominającym przyszły ruch sieciowy. Dopiero w połączeniu dane te pokazują, czy istotne strumienie są faktycznie przetwarzane w sprzęcie, czy też host nadal ponosi decydującą część obciążenia ścieżki danych.

W celu przeprowadzenia porównania operatorzy powinni uwzględnić te same rozmiary pakietów, protokoły, liczbę połączeń i wytyczne zarówno przed, jak i po wprowadzeniu zmiany. Czysta przepustowość gigabitowa może łatwo maskować wąskie gardło w przypadku małych pakietów lub dużej liczby równoległych strumieni. Równie ważne są opóźnienia, czas procesora na każdy zaangażowany host, obciążenie Softirq, utrata pakietów w kolejkach oraz rozkład ruchu na węzłach i portach.

Poniższe polecenia nie powodują zmian w konfiguracji. Pierwsze zapytanie uwzględnia zarówno urządzenia PCI wyświetlane jako kontrolery Ethernet, jak i te wyświetlane jako kontrolery sieciowe. ethtool -k pokazuje oferowane lub aktywowane w Netdev funkcje odciążania, ale nie potwierdza w pełni ani odciążania eSwitch, ani SmartNIC, ani odciążania przepływu. Pozostałe wyniki to również dane inwentaryzacyjne i konfiguracyjne, a nie dowód na istnienie konkretnej, w pełni odciążonej reguły.

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

W przypadku Open vSwitch należy w szczególności rozróżnić między skonfigurowaną akceleracją sprzętową a zaobserwowanym wynikiem. Dokumentacja programistyczna OVS 4.0.90 określa funkcję sprzętowego odciążania przepływu jako eksperymentalną i opisuje całkowite lub częściowe odciążanie wyłącznie dla tej konfiguracji OVS z DPDK. W związku z tym w środowisku produkcyjnym informacje o przepływie i liczniki sprzętowe należy analizować łącznie z licznikami oprogramowania hosta.

Monitorowanie wymaga ponadto odniesienia czasowego. Krótki test może potwierdzić poprawność reguł, podczas gdy profil zbliżony do warunków produkcyjnych może później wywołać wykorzystanie pojemności tabel, rzadkie ścieżki protokołów lub rekonfiguracje. Dlatego warto odnotować wartości normalne i odchylenia dla poszczególnych modeli kart, wersji oprogramowania układowego, sterowników i platform. Dzięki temu po aktualizacjach można sprawdzić, czy Ścieżka danych lub po prostu zmieniło się obserwowane obciążenie.

W integracji z OpenShift 4.22 widok musi dodatkowo obejmować całą ścieżkę komunikacyjną. Udokumentowana obsługa odciążania sprzętowego dotyczy wyłącznie określonych obciążeń i typów komunikacji. Jeśli węzeł zgodny z OpenShift komunikuje się z węzłem nieposiadającym odpowiedniej karty SmartNIC, ten ostatni przetwarza swoją część w jądrze systemu; punkty pomiarowe na tylko jednym hoście mogą wówczas nieodzwierciedlać w pełni ścieżki typu end-to-end.

Typowe scenariusze błędów i ścieżki ponownego wystąpienia błędu

Najczęstszym objawem usterki jest niepełne przeniesienie danych. Przepływ można rozpoznać na podstawie prostych cech sprzętowych, jednak w przypadku nieobsługiwanej akcji musi on częściowo lub całkowicie powrócić do ścieżki programowej. Eksperymentalna dokumentacja OVS 4.0.90 opisuje to częściowe odciążenie dla konfiguracji DPDK. Nie jest to ogólne stwierdzenie dotyczące każdej instalacji OVS, ale wyjaśnia, na co należy zwrócić uwagę przy każdej konkretnej integracji.

Diagnoza rozpoczyna się wzdłuż rzeczywistej ścieżki: port wejściowy, funkcja wirtualna lub reprezentator, reguła przełącznika, przetwarzanie tunelu lub polityki oraz obciążenie docelowe. Jeśli liczniki przed i za danym etapem nie są ze sobą spójne w sposób wiarygodny, stanowi to powód do sprawdzenia dopasowań, akcji i rozwiązań awaryjnych. Włączona funkcja nie zastępuje tego przyporządkowania, ponieważ możliwości karty nie obejmują każdej pożądanej kombinacji reguł.

Klastry heterogeniczne utrudniają porównanie. W przypadku OpenShift 4.22 odciążanie sprzętowe ma miejsce tylko wtedy, gdy powiązane pody i usługi są przypisane do węzłów wyposażonych w kompatybilną kartę SmartNIC. Jeśli taka ścieżka napotka zwykły węzeł, przetwarzanie odbywa się w jądrze, co ogranicza całkowity przepływ danych. Dlatego pojedynczy węzeł z akceleracją nie zajmuje w całości ścieżki klastra z akceleracją.

Również nieodpowiednia konfiguracja podów lub sieci może uniemożliwić osiągnięcie oczekiwanego efektu. Firma Red Hat wyraźnie zwraca uwagę, że w przypadku funkcji OpenShift 4.22 włączone odciążanie sprzętowe bez odpowiednio skonfigurowanych podów może pogorszyć przepustowość podów. Operatorzy nie powinni zatem reagować na odchylenia od oczekiwanych wyników poprzez dalsze włączanie opcji, lecz najpierw sprawdzić połączenia obciążeń, tryb sieciowy oraz faktycznie osiągane przepływy.

Zmiany w zdolności regulacyjnej i odchylenia w oprogramowaniu układowym należą do tej samej klasy błędów: w przypadku wielu klientów, krótkotrwałych połączeń lub dynamicznych zasad odpowiednia wielkość przepływu może rosnąć inaczej niż oczekiwano. Sterownik powiązany z konkretną wersją lub odmienne oprogramowanie sprzętowe mogą ponadto oferować funkcje w sposób odmienny od tego, jaki przewiduje planowana kombinacja platform. Dlatego dane inwentaryzacyjne i liczniki należy zawsze archiwizować wraz z konkretnym zestawem reguł.

A kontrolowana ścieżka powrotu umożliwia diagnozowanie działania systemu. Oznacza to, że przetwarzanie programowe pozostaje jako przewidziana alternatywa, a zmiany są wdrażane stopniowo, z wykorzystaniem okna porównawczego i jasnych kryteriów przerwania. Rezerwa programowa nie jest przy tym automatycznie usterką, lecz może stanowić oczekiwany sposób obsługi działań, których wybrana ścieżka sprzętowa nie obsługuje w pełni.

Realistyczne podejście do zaopatrzenia i eksploatacji

Decyzja o zakupie zaczyna się od obciążenia, a nie od prędkości portu czy nazwy produktu. Zastosowanie specjalistycznego sprzętu ma sens tam, gdzie powtarzające się przetwarzanie pakietów w sposób wyraźny pochłania czas procesora: na przykład w przypadku licznych sieci wirtualnych, stałych zestawów reguł, ruchu typu overlay lub zdefiniowanej ścieżki szyfrowania. W przypadku braku takich dowodów prostszym rozwiązaniem może być optymalizacja procesora i kolejek lub zastosowanie klasycznej karty sieciowej z odpowiednimi podstawowymi funkcjami odciążającymi.

Następnie należy Certyfikat zgodności dla konkretnej kombinacji: model karty i tryb pracy, oprogramowanie układowe, sterowniki, jądro, przełącznik wirtualny lub CNI, a także niezbędne funkcje dopasowania i działania. Programowalne akceleratory infrastruktury mogą na przykład zapewniać odciążanie przepływu dla funkcji związanych ze stanem lub sesją; nie oznacza to jednak, że każda karta SmartNIC lub każda platforma zapewnia tę samą funkcję.

Oczekiwane odciążenie procesora staje się dostępne jako wolna pojemność dopiero wtedy, gdy przetwarzanie pakietów stanowiło dotychczasowe wąskie gardło, a zwolnione rdzenie można sensownie wykorzystać. Jeśli zostaną one na przykład przeznaczone na bazy danych, procesy internetowe lub rezerwy, jest to decyzja architektoniczna, a nie automatyczny wzrost wydajności. Pozostałe elementy wyposażenia serwera mają zatem kluczowe znaczenie; procesor, pamięć operacyjna i pamięć masowa muszą być dostosowane do aplikacji w takim samym stopniu, jak sieć. Więcej informacji na temat całościowej oceny można znaleźć w artykule na temat sprzęt serwerowy mający wpływ na wydajność w hostingu internetowym.

W przypadku protokołu IPsec weryfikacja ma szczególnie konkretny charakter: udokumentowane warianty odciążania obejmują zarówno odciążanie kryptograficzne, jak i całkowite przeniesienie funkcji enkapsulacji, dekapselacji, szyfrowania oraz ochrony przed ponownym odtworzeniem. To, który wariant jest dostępny, zależy od modelu, generacji, oprogramowania układowego oraz konfiguracji kryptograficznej. Informacje dotyczące konkretnych produktów mogą ponadto zawierać ograniczenia dotyczące określonych generacji lub przepustowości; należy je uwzględnić w procesie weryfikacji przed wdrożeniem.

Karta DPU rozszerza zakres decyzji o własną strefę zarządzania i zaufania. W trybie BlueField-DPU zintegrowany system Arm kontroluje zasoby karty sieciowej (NIC) oraz ścieżkę danych, zamiast tego, by karta działała wyłącznie jako adapter hosta. Pozwala to oddzielić zadania infrastrukturalne od hosta, wymaga jednak solidnej koncepcji dotyczącej praw dostępu, obrazów, aktualizacji, monitorowania i przywracania danych.

Z ekonomicznego punktu widzenia liczy się zatem nie tylko cena karty. Należy również wziąć pod uwagę zaoszczędzoną lub unikniętą moc obliczeniową procesora hosta, przewidywaną żywotność platformy, a także dodatkowe nakłady związane z certyfikacją, częściami zamiennymi, aktualizacją oprogramowania układowego i przywracaniem sprawności po awarii. Zastosowanie karty SmartNIC ma sens, jeśli ta kalkulacja opiera się na powtarzalnej ścieżce danych i cyklu życia, który można trwale kontrolować – a nie dlatego, że wyspecjalizowany sprzęt z zasady wydaje się szybszy.