NAPI vs przerwań adaptacyjnych

Czy ktoś mógłby wyjaśnić, w jaki sposób stosuje się dwie następujące technologie w celu zmniejszenia obciążenia związanego z przerwaniem przy dużym obciążeniu sieci?

1. Adaptive-rx / Adaptive-tx i
2. NAPI;

Byłbym wdzięczny za odpowiedź, która wyjaśnia różnicę bliższą poziomowi źródła jądra Linux? Chciałbym również usłyszeć, jak zmusić kartę sieciową do przeszukiwania / przerywania trybu koalescencji przy obciążeniu wynoszącym ~ 400 Mb / s.

Więcej tła:

Problem polega na tym, że sterowniki bnx2 i e1000 ignorują polecenie „ethtool -C adaptive-rx on”. Jest to prawdopodobnie spowodowane tym, że sterowniki te nie obsługują przerwań adaptacyjnych. Chociaż instrukcja obsługi Broadcom Programmer mówi, że ta funkcja powinna być obsługiwana przez sprzęt BCM5709 NIC.

Postanowiłem więc wypróbować NAPI i zmniejszyć wagę z 64 do 16 w wywołaniu funkcji netif_napi_add (), aby wymusić działanie karty sieciowej w trybie odpytywania przy znacznie mniejszym obciążeniu, ale niestety to nie zadziałało. Myślę, że NAPI nie potrzebuje żadnej specjalnej obsługi sprzętowej w NIC, czy to prawda?

Używany przeze mnie sprzęt to BCM5709 NIC (używa sterownika bnx2). System operacyjny to Ubuntu 10.04. Procesor to XEON 5620.

Główną zasadą moderowania przerwań jest generowanie mniej niż jednego przerwania na odebraną ramkę (lub jednego przerwania na zakończenie ramki nadawczej), zmniejszając obciążenie systemu operacyjnego napotkane podczas obsługi przerwań. Kontroler BCM5709 obsługuje kilka metod sprzętowych przerwań koalescencyjnych, w tym:

• Wygeneruj przerwanie po otrzymaniu ramek X (ramki rx w ethtool)
• Generuj przerwanie, gdy nie otrzyma więcej ramek po X usecs (rx-usecs w ethtool)

Problem z użyciem tych metod sprzętowych polega na tym, że musisz je wybrać, aby zoptymalizować przepustowość lub opóźnienie, nie możesz mieć obu. Generowanie jednego przerwania dla każdej odebranej ramki (rx-frames = 1) minimalizuje opóźnienie, ale robi to kosztem pod względem kosztów usługi przerwań. Ustawienie większej wartości (powiedzmy rx-frames = 10) zmniejsza liczbę zużytych cykli procesora, generując tylko jedno przerwanie na każde dziesięć odebranych ramek, ale wystąpi również większe opóźnienie dla pierwszych ramek w tej grupie dziesięciu.

Implementacja NAPI próbuje wykorzystać fakt, że ruch przychodzi w pęczkach, aby natychmiast wygenerować przerwanie na pierwszej odebranej ramce, a następnie natychmiast przejść do trybu odpytywania (tj. Wyłączyć przerwania), ponieważ większy ruch będzie blisko. Po odpytywaniu o pewną liczbę ramek (16 lub 64 w pytaniu) lub jakiś przedział czasu, sterownik ponownie włączy przerwania i zacznie od nowa.

Jeśli masz przewidywalne obciążenie pracą, możesz wybrać stałe wartości dla dowolnego z powyższych elementów (NAPI, ramki rx, rx-usecs), które zapewniają odpowiedni kompromis, ale większość obciążeń różni się i kończysz się pewnymi poświęceniami. Właśnie tutaj wchodzą w grę adaptive-rx / adaptive-tx. Chodzi o to, że sterownik stale monitoruje obciążenie pracą (ramki odbierane na sekundę, rozmiar ramki itp.) I dostraja schemat koalescencji przerwań sprzętowych, aby zoptymalizować opóźnienia w sytuacjach o małym natężeniu ruchu lub zoptymalizować przepustowość w sytuacjach o dużym natężeniu ruchu. To fajna teoria, ale może być trudna do wdrożenia w praktyce. Zaimplementowało go tylko kilka sterowników (patrz http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ), a sterowników bnx2 / e1000 nie ma na tej liście.

Aby uzyskać dobry opis działania każdego pola koalescencyjnego ethtool, zapoznaj się z definicjami struktury ethtool_coalesce pod następującym adresem:

http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111

W konkretnej sytuacji (przepustowość ~ 400 Mb / s) sugeruję dostrajanie ramek rx i wartości rx-usecs, aby uzyskać najlepsze ustawienia dla obciążenia. Przyjrzyj się zarówno narzutowi ISR, jak i wrażliwości aplikacji (httpd? Itd.) Na opóźnienia.

Dave