Interesują mnie konkretne odpowiedzi:
- Czy karta sieciowa z GRO edytuje / tworzy TCP ACK lub jakiekolwiek inne pakiety (czy też ta funkcja jest przezroczysta dla stosów TCP odbiorcy / nadawcy)?
- Powinien istnieć limit czasu / zdarzenie, w którym karta sieciowa powinna przekazać „segmenty sklejone” do stosu TCP? Czym oni są?
- W konfiguracji przekazywania pakietów - czy funkcja GRO próbuje również czytać potwierdzenia ACK odbiorcy (patrz poniżej, dlaczego o to pytam)?
- Wszelkie źródła, które wyjaśniają GRO, a także inne funkcje rozładowywania kart sieciowych (TSO, LSO ...) lepsze niż strony podręczników wikipedii i linuxa, byłyby bardzo mile widziane.
Więcej szczegółów:
Rozwiązuję problem wydajności z jedną implementacją IPSec. Problem polega na tym, że dostępna przepustowość nie jest równomiernie rozłożona na wszystkie 4 tunele VPN (rozproszone w przybliżeniu jako 200 MB / 200 MB / 1 MB / 1 MB / s; każdy tunel VPN zawiera pojedyncze połączenie TCP). W PCAP raz na jakiś czas widzę, że ten serwer działa na biegu jałowym przez około 2 sekundy (oczekiwanie na potwierdzenie). Pobieranie jest wznawiane, gdy serwer WWW ponownie przesyła niepotwierdzone segmenty.
Moje wewnętrzne wycięcie z PCAP polega na tym, że NIC GRO zawiera pakiety klejów razem, ale czasami nie przekazuje ich na stos TCP w odpowiednim czasie i to powoduje problemy.
Ponieważ ten serwer VPN nie ma interfejsów, które kończą połączenia TCP, a jedynie przekazuje pakiety. Następnie próbowałem wyłączyć GRO, a potem zauważyłem, że ruch był równomiernie rozłożony we wszystkich tunelach. Również gdy skalowanie okna TCP jest wyłączone na serwerze WWW, przepustowość jest nawet dystrybuowana nawet przy włączonej GRO (dlatego miałem pytanie nr 3).
Używam Linuksa 2.6.32-27 na serwerze Ubuntu 10.04 (64-bit). Karta sieciowa to Intel 82571EB. Wszystkie interfejsy (klient HTTP, klient VPN, serwer VPN, serwer WWW) są połączone bezpośrednio w łańcuch za pomocą kabli Ethernet 1Gbit.