Jak zbudować wysokowydajny stos TCP/IP działający w przestrzeni użytkownika (userspace), na bazie tradycyjnej implementacji z jądra systemu FreeBSD?

1. Jak stworzyć wysokowydajny i skalowalny stos
sieciowy dla 72 rdzeni CPU ?
Trzeci Wieczór Technologii Sieciowych
15 października 2014

2. 1. Wstęp
2. Opis referencyjnej platformy
3. Budowa stosu TCP/IP w kontekście użytej platformy
4. Wyniki
5. Pytania

3. Wstęp
● Wysoka przepustowość
● Niskie opóźnienia
● Liczba połączeń/s
(nawiązywanie i
kończenie)

4. 1.Wstęp
2.Opis referencyjnej platformy
3.Budowa stosu TCP/IP w kontekście użytej
platformy
4.Wyniki
5.Pytania

5. •
•
•
•

7. ● Lokalny cache L1 i L2
● “Wspólny” cache L3
○ Możliwy dostęp do L2 innego tile’a
● Memory homing
○ Local homing
○ Remote homing
○ Hash for homing

9. Programowalny, inteligentny silnik dla pakietów
● Parsowanie nagłówków
● Dystrybucja pakietów
● Zarządzanie buforami
● Load balancing
● Obliczanie sumy kontr. L4 podczas odbierania i
wysyłania pakietów (offload)
● Scatter/gather pakietów będących łańcuchem
buforów

10. 1. ę
2.
3. Budowa stosu TCP/IP w kontekście użytej
platformy
4.
5.

12. ł ł ń

13. Ważne biblioteki Netliba
● Zero Overhead Linux (ZOL)
○ jeden wątek 'przypięty' do jednego Tile'a
○ żadnych przerwań, przełączania kontekstu i
syscall'i
● Nieznaczna modyfikacja biblioteki pthreads
○ Podanie numeru Tile'a na którym uruchamiamy
wątek

14. Różne ścieżki dla pakietu

15. ● Jeden proces składa się z wielu wątków
● Każdy wątek działa na osobnym Tile'u
● Każdy Tile zajmuje się przetwarzaniem przychodzących i wychodzących
pakietów dla danego połączenia TCP/IP (run-to-completion)
● Dane połączenie TCP/IP jest zawsze przetwarzane przez ten sam Tile
(static flow affinity) dzięki algorytmowi hashowania połączeń (konfiguracja
dla mPIPE)
Takie założenia pozwalają na:
● eliminację locków dla struktur specyficznych dla danego połączenia TCP
● zmniejszenie ilości lokalnych PCB dla Tile'a a przez to zmniejszenie czasu
spędzonego na ich wyszukiwaniu, tworzeniu itp.
● optymalizację dostępu do pamięci cache

16. Jak zapewnić flow affinity
● Ingress
○ mPIPE oblicza hash na podstawie czwórki (adresu IP źródła,
przeznaczenia oraz portów) dla każdego przychodzącego
pakietu
○ Algorytm zwraca numer tile'a gdzie pakiet ma być przekazany
● Egress
○ Ten sam scenariusz obowiązuje podczas nawiązywania
połączenia TCP na tile'u gdzie działa aplikacja
○ Aplikacja dostaje zestaw kolejek za pomocą których zawsze
wysyła pakiety do tego samego CPU

17. ł
…

18. •Przetwarzanie połączenia TCP (kod z FreeBSD)
•Przetwarzanie wiadomości w kolejce kontrolnej
•Przetwarzanie pakietów w kolejkach Rx/Tx
•Zarządzanie kolejką z buforami -
alokacja/de-alokacja

19. Kolejki między 'Network stack tile' a
'Application tile'
● Kolejka danych - Data Communication
○ Jedna dla każdego połączenia TCP
○ Zawierają pakiety z danymi
○ Żadnych locków po stronie 'Network stack tile'
○ Służy jako ‘socketbuf’ ekwiwalent dla stosu FreeBSD
● Kolejka z wiadomościami kontrolnymi
○ Jedna na każdego 'Network stack tile'
○ Zawiera wiadomości specyficzne dla połączenia TCP takie jak
connect, listen, etc.
● Kolejki z buforami
○ Jedna na każdego 'Network stack tile'
○ Opisana w dalszej części prezentacji

20. Alokacja/dealokacja
Dodaj nowy bufor
albo re-użyj
Kolejka z pustymi buforami
Kolejka z buforami do dealokacji
Zdjęcie bufora
Zwrócenie buforaDealokacja bufora

21. Jak uniknąć kopiowania pakietów - zero-copy
● Ten sam pakiet musi być widziany przez hardware (mPIPE), CPU na
którym działa stos i aplikacja
● Zastosowane rozwiązanie
○ Dedykowane strony pamięci dostępne bezpośrednio przez mPIPE
○ Zestaw buforów (prealokowanych z tych samych stron pamięci) dla
każdego CPU gdzie działa stos (Network stack tile)
○ Każdy bufor musi być zwrócony do tego samego CPU z którego był
wzięty (kolejka z buforami)
○ Tylko mPIPE oraz CPU gdzie działa stos może alokować/dealokować
bufory

22. ● Podobne do funkcji socket'owych:
○ listen(), bind(), connect(), send(), receive(), etc.
● Zawsze tryb non-blocking
● Sposób pracy bazuje na pollingu
● Dostarcza funkcje, które pozwalają manipulować
buforami
○ Konieczne dla podejścia 'zero-copy’
○ Pozwala na alokacje, rozszerzenie, zmniejszenie
buforów itp.

23. ● Inspirowane LwIP
● Implementacja w oparciu o raw/native API
● Kompatybilność z Unix socekt API
● API łatwiejsze do użycia dla piszącego aplikację
● Niższa wydajność w porównaniu z raw/native API
○ Konieczność kopiowania

24. Jak pozbyć się locków
● Każdy tile ma przypisany tylko jeden wątek
● Każde połączenie TCP jest obsługiwane tylko przez
jeden tile
● Tylko jeden otwarty socket na tile'u gdzie działa
aplikacja
○ Kolejka z buforami
○ Kolejka z pakietami Rx/Tx
○ Kolejka z kontrolnymi wiadomościami

25. 1. Wstęp
2.
3. Budowa stosu TCP/IP w kontekście użytej
platformy
4.
5.

26. Środowisko testowe
● ‘ab’ - liczba połączeń/s (nawiązywanie i kończenie)
● Infinicore – TCP/IP tester
● Iperf oraz prosta aplikacja ‘echo’ mierząca
przepustowość
● Liczniki hardwarowe mierzące opóźnienia
wprowadzone przez stos

27. Przepustowość

28. Przepustowość

29. Przepustowość

30. Przepustowość

31. Przepustowość vs skalowalność

32. Opóźnienie

33. Liczba połączeń/s
● Najtrudniejsze do osiągnięcia
● Około 700k/s z 16 rdzeniami
○ Wynik ograniczony przez środowisko testowe