Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Jak stworzyć wysokowydajny i skalowalny stos sieciowy dla 72 rdzeni CPU?

190 views

Published on

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

Published in: Software
  • Login to see the comments

  • Be the first to like this

Jak stworzyć wysokowydajny i skalowalny stos sieciowy dla 72 rdzeni CPU?

  1. 1. Jak stworzyć wysokowydajny i skalowalny stos sieciowy dla 72 rdzeni CPU ? Trzeci Wieczór Technologii Sieciowych 15 października 2014
  2. 2. 1. Wstęp 2. Opis referencyjnej platformy 3. Budowa stosu TCP/IP w kontekście użytej platformy 4. Wyniki 5. Pytania
  3. 3. Wstęp ● Wysoka przepustowość ● Niskie opóźnienia ● Liczba połączeń/s (nawiązywanie i kończenie)
  4. 4. 1.Wstęp 2.Opis referencyjnej platformy 3.Budowa stosu TCP/IP w kontekście użytej platformy 4.Wyniki 5.Pytania
  5. 5. • • • •
  6. 6. ● 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
  7. 7. 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
  8. 8. 1. ę 2. 3. Budowa stosu TCP/IP w kontekście użytej platformy 4. 5.
  9. 9. ł ł ń
  10. 10. 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
  11. 11. Różne ścieżki dla pakietu
  12. 12. ● 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
  13. 13. 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
  14. 14. ł …
  15. 15. •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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. ● 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.
  20. 20. ● 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
  21. 21. 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
  22. 22. 1. Wstęp 2. 3. Budowa stosu TCP/IP w kontekście użytej platformy 4. 5.
  23. 23. Ś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
  24. 24. Przepustowość
  25. 25. Przepustowość
  26. 26. Przepustowość
  27. 27. Przepustowość
  28. 28. Przepustowość vs skalowalność
  29. 29. Opóźnienie
  30. 30. Liczba połączeń/s ● Najtrudniejsze do osiągnięcia ● Około 700k/s z 16 rdzeniami ○ Wynik ograniczony przez środowisko testowe

×