Linux 7.3 przyspieszy sieci nakładkowe. BIG TCP, szybsze reguły routingu i eksperyment z AI

Zmiany sieciowe, które trafiły do głównej gałęzi Linuksa 20 sierpnia 2026 r., są interesujące z dwóch powodów. Z jednej strony poprawiają skalowanie obciążeń korzystających z tuneli nakładkowych i wielu przestrzeni nazw. Z drugiej pokazują, jak opiekunowie jądra próbują odpowiedzieć na rosnącą liczbę poprawek tworzonych z pomocą sztucznej inteligencji. Linux 7.3 nie jest jeszcze stabilnym wydaniem — opisany kod trafił do głównej gałęzi w trakcie okna scalania.

BIG TCP trafia do VXLAN i Geneve

Najważniejszą zmianą w ścieżce danych jest rozszerzenie BIG TCP na sterowniki UDP-owych tuneli VXLAN i Geneve. Mechanizm pozwala jądru operować wewnętrznie na pakietach większych niż 64 KiB, a następnie podzielić ruch za pomocą GSO i TSO, zanim zostanie wysłany przez interfejs sieciowy. Nie chodzi więc o przesyłanie zbyt dużych pakietów po sieci, lecz o ograniczenie kosztu przetwarzania kolejnych pakietów w ścieżce overlay.

Wyniki testu

netperf TCP_STREAM

• przepustowość VXLAN przy standardowym MTU wzrosła z 34,44 do 39,56 Gbit/s, czyli o 14,9 proc.;
• po wyłączeniu sprzętowego offloadingu tunelu wynik VXLAN poprawił się z 21,82 do 29,39 Gbit/s, czyli o 34,7 proc.;
• Geneve przy standardowym MTU osiągnął wzrost z 37,39 do 40,89 Gbit/s, czyli o 9,4 proc.

To nie są jednak uniwersalne obietnice dotyczące wydajności każdego systemu z Linuksem 7.3. Rezultat zależy między innymi od wartości gso_max_size i gro_max_size, możliwości karty sieciowej, ustawień offloadingu, MTU, rodzaju tunelu oraz charakterystyki obciążenia. Administratorzy powinni zmierzyć własną ścieżkę VXLAN lub Geneve przed przyjęciem podobnych procentowych wzrostów.

Mniej blokowania RTNL przy zmianach routingu

Drugim dużym elementem jest ograniczenie zależności od szerokiej blokady RTNL podczas dodawania i usuwania reguł FIB dla IPv4 i IPv6. Tam, gdzie jest to możliwe, operacje korzystają teraz z mutexów powiązanych z odpowiednim fib_rules_ops, dzięki czemu część zadań może wykonywać się równolegle. RTNL nadal jest potrzebna w niektórych przypadkach, między innymi w ścieżce fib_unmerge() dotyczącej pierwszej reguły IPv4.

W syntetycznym teście, który mocno obciążał mechanizm blokad, równoległe utworzenie 4096 przestrzeni sieciowych i dodanie do każdej z nich 1024 reguł skróciło czas dla IPv4 z 22,752 do 0,918 sekundy — około 24,8 raza. Dla IPv6 wynik poprawił się z 35,181 do 1,214 sekundy, czyli około 29 razy.

To pomiar skrajnego rywalizowania o blokady, a nie gwarantowany wzrost szybkości uruchamiania każdego kontenera. Największe znaczenie zmiana może mieć w infrastrukturze, która jednocześnie tworzy i konfiguruje dużą liczbę przestrzeni sieciowych.

Opiekunowie jądra są „całkowicie przytłoczeni” poprawkami AI

W tym samym merge pojawił się nietypowy wątek dotyczący organizacji pracy nad jądrem. Jakub Kicinski poinformował o 632 poprawkach net i 648 poprawkach net-next. Ocenił, że około jedna trzecia do połowy zmian w net-next stanowiły generowane przez AI poprawki o niskim priorytecie, porządki w kodzie lub doprecyzowania. Oznaczałoby to około 216–324 poprawek. Kicinski i Paolo Abeni opisali powstałe obciążenie jako „całkowicie przytłaczające”.

Planowana odpowiedź nie polega na przekazaniu decyzji jednemu modelowi. Meta zapewniła budżet i dostęp do wielu zaawansowanych modeli AI, aby każda poprawka mogła przejść kilka wstępnych ocen. Ma to ograniczyć ryzyko, że halucynacja lub błędna interpretacja jednego modelu przejdzie dalej bez odpowiedniej kontroli.

Automatyzacja może objąć zarządzanie Patchworkiem, przekazywanie rutynowych uwag dotyczących procesu, redagowanie opisów commitów, a w przyszłości także stosowanie poprawek wcześniej sprawdzonych przez zaufane osoby. Są to zadania bardziej uporządkowane niż rozstrzyganie, czy zmiana jest bezpieczna w rzadkiej ścieżce awarii.

To rozróżnienie ma w jądrze szczególne znaczenie. Nietypowe wyścigi, obsługa błędów PCIe i procedury reagowania na przekroczenie czasu nadal wymagają ludzkiej analizy. AI może odciążyć opiekunów przy powtarzalnej pracy, ale nie zastępuje rozumienia współbieżności, kontraktów API ani kolejności operacji podczas odzyskiwania systemu.

Nowe sterowniki i usprawnienia protokołów

W pakiecie zmian znalazły się również elementy obsługi sprzętu i protokołów:

• początkowy sterownik Morse Micro mm81x dla Wi-Fi HaLow obsługuje urządzenia USB i SDIO;
• pojawił się nowy sterownik bezprzewodowy NXPWIFI, a prace nad trybem wielołączowym są kontynuowane;
• Intel otrzymał początkowy szkielet sterownika iXD dla obsługi Control Plane PIC Function w układach IPU i kartach FNIC od E2100 wzwyż;
• w sieciach przewodowych dodano początkową obsługę CXL dla kart AMD/Solarflare oraz możliwość aktualizowania firmware’u sprzętu AMD Pensando.

MPTCP zyskał awaryjny mechanizm usuwania kolejek pakietów przychodzących poza kolejnością w warunkach skrajnego niedoboru pamięci. To zabezpieczenie na trudne sytuacje, a nie obietnica wyższej przepustowości podczas normalnej pracy.

Łatwiejsza będzie także diagnostyka przekazywania deskryptorów plików przez AF_UNIX. Po użyciu SO_RIGHTS_NOTRUNC odbiorca może ustalić, który deskryptor został odrzucony przez moduł bezpieczeństwa LSM, i odczytać odpowiadający mu errno. Nie musi już tracić informacji o pozostałej części tablicy SCM_RIGHTS po pierwszym odrzuceniu.

Kiedy Linux 7.3 trafi do użytkowników?

Pierwszy kandydat do wydania, Linux 7.3-rc1, był przewidywany w okolicach 30 sierpnia 2026 r., a stabilne wydanie — na koniec października, jeśli cykl rozwoju przebiegnie zgodnie z planem.

Nie oznacza to, że większość serwerów i komputerów otrzyma te funkcje już w październiku. Dystrybucje wybierają własne wersje jądra, selektywnie przenoszą poprawki, przeprowadzają testy i publikują aktualizacje według odrębnych harmonogramów. Dystrybucje kroczące mogą udostępnić kernel wcześniej, podczas gdy w wydaniach o stałym cyklu oczekiwanie może potrwać znacznie dłużej.

CachyOS, jako dystrybucja krocząca, może znaleźć się wśród wcześniejszych użytkowników, ale dostępne informacje z sierpnia nie potwierdzają konkretnej daty przejścia na Linuxa 7.3. Obrazy instalacyjne z tego miesiąca korzystały jeszcze z jąder 7.1.

Co ta zmiana oznacza w praktyce?

Dla zespołów infrastrukturalnych najważniejsze są dziś dwie kwestie: BIG TCP w ścieżce tuneli nakładkowych oraz mniejsza rywalizacja o blokady podczas masowego zarządzania regułami sieciowymi w przestrzeniach nazw. Warto je obserwować szczególnie w środowiskach, które łączą VXLAN lub Geneve z ruchem o wysokiej przepustowości albo równolegle uruchamiają wiele namespace’ów.

Dla deweloperów jądra równie ważny może być eksperyment z AI. Wstępny podział pracy wygląda praktycznie: modele przejmują powtarzalny triage i uwagi proceduralne, a opiekunowie zachowują odpowiedzialność za rzadkie przypadki, w których pozornie poprawna łatka może doprowadzić do zakleszczenia, błędnej obsługi awarii lub naruszenia niejawnych zasad synchronizacji.

Linux 7.3 zapowiada więc obszerny zestaw zmian sieciowych, ale przed szerokim zastosowaniem potrzebuje jeszcze testów kandydatów do wydania, walidacji na sprzęcie oraz integracji w poszczególnych dystrybucjach.