AES-NI w OpenSSL czy odciążenie jądra: czego naprawdę potrzebujesz?

Dwa określenia bywają używane tak, jakby znaczyły to samo: przyspieszone sprzętowo i odciążone do jądra. Pierwsze opisuje, jakie instrukcje wykonuje procedura AES biblioteki, drugie opisuje, gdzie odbywa się przetwarzanie pakietów. VPN może mieć pierwsze bez drugiego, drugie bez pierwszego albo oba naraz. Każda decyzja o wydajności musi zaczynać się od nazwania, które z tych dwóch naprawdę zmieniasz.

Dwie osie, nie jeden wynik

Pierwsza oś to implementacja: czy kod wykonujący AES-256-GCM trafia do wersji korzystającej z dedykowanych instrukcji procesora, czy do przenośnej procedury wykonującej je jako zwykłą arytmetykę. Ten wybór mieszka wewnątrz biblioteki kryptograficznej i jest podejmowany przy jej inicjalizacji.

Druga oś to umiejscowienie: czy pakiet przechodzi ścieżką transformacji jądra, czy demon w przestrzeni użytkownika czyta z urządzenia tunelowego, szyfruje i zapisuje z powrotem.

Żadna oś nie ogranicza drugiej. VPN w przestrzeni użytkownika na procesorze z instrukcjami AES może ich używać przez cały czas, a ścieżka jądra na procesorze bez nich wraca do implementacji programowej. Etykiety w materiałach dostawców rzadko robią to rozróżnienie, dlatego porady dotyczące strojenia kopiowane między obiema sytuacjami tak często nic nie dają.

Oś pierwsza: który kod wykonuje szyfrowanie

OpenSSL wykrywa cechy procesora podczas inicjalizacji i używa wyniku do wyboru zoptymalizowanych ścieżek kodu, jak opisuje dokumentacja możliwości x86. AES-NI jest jedną z udokumentowanych możliwości stojących za tym kierowaniem. Nic z tego nie wymaga, by biblioteka stała się składnikiem jądra.

Potwierdź, że cecha jest widoczna dla procesu, zanim uznasz, że używana jest szybka ścieżka. W Linuksie źródłem jest pole flags w /proc/cpuinfo, a wewnątrz gościa odzwierciedla ono to, co udostępnia hiperwizor, a nie nazwę modelu fizycznego hosta.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

Drugie polecenie wymienia dostawców załadowanych w tej kompilacji. Nie mówi, do której biblioteki linkuje usługa VPN, a jeden host może nosić dwie instalacje OpenSSL, podczas gdy działający proces używa tylko jednej z nich.

Oś druga: gdzie działa ścieżka pakietów

Umieszczenie w jądrze oznacza, że transformacja odbywa się w mechanizmie IPsec samego jądra lub w sterowniku tunelu w jądrze, więc pakiety nie potrzebują podróży tam i z powrotem przez proces w przestrzeni użytkownika dla każdej partii. To może ciąć kopie i przełączenia kontekstu oraz rozkładać pracę na rdzenie w sposób, na jaki nie stać demona jednowątkowego. Przenosi też liczniki i ślady, które będziesz czytać, gdy przepustowość spadnie, ponieważ praca odbywa się teraz po drugiej stronie granicy, której nie kontrolujesz. Traktuj to jako koszt debugowania, nie tylko decyzję wydajnościową.

To nie tworzy obsługi instrukcji, nie konfiguruje szyfru i nie uruchamia istniejącej trasy.

Wirtualizacja dokłada fałdę także na tej osi. Gość może dostać zamaskowany model procesora, który ukrywa cechy mające hosta, a zagnieżdżony gość może widzieć jeszcze mniej. Czytaj widok możliwości od wewnątrz środowiska, w którym VPN naprawdę działa, a nie z konsoli hiperwizora.

Co kupuje każdy wybór, a czego nie może

Praktyczne pytanie brzmi, gdzie ucieka czas. Jeśli przepustowość ogranicza jeden zajęty wątek, powtarzane kopie bufora lub wywołanie systemowe na pakiet, przeniesienie transformacji na ścieżkę, która usuwa te koszty, może pomóc, pod warunkiem że jądro implementuje potrzebną transformację.

Jeśli granicą jest przeciążone łącze wyjściowe, ścieżka z utratą pakietów, długi czas rundy, wysycony serwis docelowy albo jeden wątek przypięty do jednego rdzenia, umiejscowienie nie zmienia niczego ważnego. To samo dotyczy wyboru instrukcji: AES na dedykowanym sprzęcie nie naprawi brakującej trasy i nie pomoże, jeśli tunel stoi, bo zawodzi rozwiązywanie nazw.

Tam, gdzie działa jedno i drugie, składają się. Ścieżka jądra może używać tego samego kierowania na poziomie instrukcji wewnątrz kryptograficznego API jądra, a ścieżka w przestrzeni użytkownika z dobrze wybraną biblioteką już go używa. Decyzja nie dotyczy tego, co jest szybsze w abstrakcji, ale tego, na jaki koszt masz dowody.

Zapisz cztery fakty, zanim cokolwiek zmienisz

Zapisz plik binarny usługi i bibliotekę kryptograficzną, z którą jest zlinkowany, bo one decydują o osi pierwszej. Potem zanotuj wynegocjowaną ochronę danych, bo szyfr bez dedykowanej ścieżki instrukcji zachowuje się inaczej niż ten z nią, a zestaw wybierają obie strony.

Następnie widok możliwości od wewnątrz działającego środowiska, a na końcu aktywną ścieżkę pakietów z dowodem, że tryb, który uważasz za włączony, naprawdę jest włączony. Załadowany moduł nie jest dowodem, że profil go używa, a linia konfiguracji nie jest dowodem, że jądro ją przyjęło.

Zmień jedną rzecz, a potem porównaj z równomiernym obciążeniem przy tych samych punktach końcowych i tym samym kierunku transferu. Twierdzenie o szybkości, którego nie zmierzyłeś, jest warte mniej niż notatka, że backend nigdy nie był wątpliwy.