Linux 7.3 får BIG TCP i VXLAN och Geneve – samtidigt som AI testas för patchgranskning

Det här är mätningar för specifika konfigurationer. Resultatet påverkas bland annat av gso_max_size, gro_max_size, nätverkskortets funktioner, offload-inställningar, MTU, tunneltyp och arbetsbelastning. Den som driver VXLAN- eller Geneve-baserad infrastruktur bör därför mäta sin egen miljö innan samma förbättring förutsätts.

Mindre RTNL-serialisering vid routinguppdateringar

Sammanslagningen minskar också beroendet av det breda RTNL-låset vid tillägg och borttagning av IPv4- och IPv6-regler i FIB, kärnans Forwarding Information Base. Där det är möjligt används i stället mutex-skydd kopplat till den berörda fib_rules_ops, vilket låter fler operationer köras parallellt. RTNL behövs fortfarande i vissa fall, bland annat i fib_unmerge()-vägen för den första IPv4-regeln.

Ett syntetiskt stresstest visar den möjliga vinsten när många nätverksnamnrymder hanteras samtidigt. Att skapa 4 096 nätverksnamnrymder och lägga till 1 024 regler i varje parallellt tog för IPv4 0,918 sekunder, jämfört med 22,752 sekunder tidigare – ungefär 24,8 gånger snabbare. För IPv6 sjönk tiden från 35,181 till 1,214 sekunder, cirka 29,0 gånger snabbare.

Testet visar framför allt effekten av extrem låskonkurrens. Det är inte ett löfte om att vanlig containerstart eller alla routingarbetslaster blir lika mycket snabbare.

Därför vänder sig underhållarna till AI

Nätverksdelen av Linuxkärnan har samtidigt blivit ett testområde för AI-assisterad utveckling. Jakub Kicinski uppgav att det kommit in 632 patchar till net och 648 patchar till net-next. Han uppskattade att ungefär en tredjedel till hälften av net-next bestod av AI-drivna ändringar med låg prioritet – exempelvis mindre korrigeringar, städning och förtydliganden. Det motsvarar omkring 216–324 patchar. Kicinski och Paolo Abeni beskrev arbetsbördan som ”helt överväldigande”.

Lösningen är inte att ersätta underhållarna med en enda modell. Meta har bidragit med budget och tillgång till flera avancerade AI-modeller så att patchar kan få flera inledande granskningar. Tanken är att minska risken för att en hallucination eller feltolkning från en enskild modell passerar obemärkt.

Den planerade automatiseringen omfattar bland annat hantering i Patchwork, återkoppling på rutinprocesser och redigering av commit-meddelanden. På sikt kan systemet även komma att tillämpa patchar som redan har granskats av betrodda personer. Sådana uppgifter är mer strukturerade än att avgöra om en ändring fungerar i en ovanlig felsituation.

Just den skillnaden är central i kärnans nätverkskod. Underhållarna betonar att sällsynta race-tillstånd och vägar för maskinvaruåterställning – exempelvis hantering av PCIe-fel och timeouter – fortfarande kräver mänsklig granskning. AI kan sortera bort repetitivt arbete, men ersätter inte förståelsen för samtidighet, API-kontrakt och ordningen i en återställningsprocess.

Nya drivrutiner och protokollförbättringar

Nätverkssammanslagningen innehåller också flera steg för ny maskinvara och nya funktioner:

• Den första drivrutinen för Morse Micro mm81x stöder Wi-Fi HaLow-enheter via USB och SDIO.
• NXPWIFI kommer in som en ny trådlös drivrutin från NXP, samtidigt som arbetet med multi-link-drift fortsätter.
• Intel får det första skelettet till iXD-drivrutinen för Control Plane PIC Function-stöd på IPU:er och FNIC:er från E2100 och senare.
• Trådbundna nätverk får inledande CXL-stöd för AMD/Solarflare-nätverkskort samt stöd för att flasha firmware på AMD Pensando-hårdvara.

Även mindre förändringar kan bli användbara i praktiken. MPTCP får en sista utväg för att rensa köer med paket som kommit i fel ordning vid extrem minnespress. Det är främst en återhämtningsmekanism för pressade situationer, inte ett löfte om högre normal genomströmning.

Det blir också enklare att felsöka filbeskrivare som skickas via AF_UNIX. Med SO_RIGHTS_NOTRUNC kan mottagaren se vilken filbeskrivare som avvisades och vilket errno som rapporterades när ett LSM blockerar en viss filbeskrivare i en SCM_RIGHTS-array. Resten av arrayen går då inte förlorad vid det första avslaget.

När kommer Linux 7.3?

Den första release candidate-versionen av Linux 7.3 väntades omkring 30 augusti 2026, medan den stabila versionen beräknades komma i slutet av oktober, förutsatt att utvecklingscykeln följer planen.

Det innebär dock inte att de flesta servrar och datorer får funktionerna redan i oktober. Distributionerna väljer själva kärnversioner, bakåtanpassar utvalda ändringar, genomför egna tester och publicerar uppdateringar enligt separata tidplaner. Rullande distributioner kan paketera kärnan tidigare, medan distributioner med fasta utgåvor kan behöva betydligt längre tid.

CachyOS är en tänkbar tidig användare eftersom distributionen följer en rullande modell. De tillgängliga augustiuppgifterna visar dock att dess installationsavbilder fortfarande använde Linux 7.1 och bekräftar inget datum för övergången till Linux 7.3.

Vad betyder detta i praktiken?

För driftteam är BIG TCP i overlay-vägar och den minskade låskonkurrensen vid storskalig hantering av nätverksnamnrymder de mest omedelbart intressanta nyheterna. De är särskilt värda att följa i miljöer där VXLAN eller Geneve kombineras med hög trafikvolym, eller där många namnrymder skapas och konfigureras samtidigt.

För kärnutvecklare kan AI-experimentet bli minst lika betydelsefullt. Sammanslagningen pekar mot en tydlig arbetsfördelning: modeller kan ta hand om repetitiv sortering och rutinmässig återkoppling, medan underhållarna behåller ansvaret för de ovanliga fall där en till synes rimlig patch kan orsaka dödläge, hantera återställning fel eller bryta mot en implicit synkroniseringsregel.

Linux 7.3 går därmed mot en omfattande nätverksuppdatering. Men innan de flesta användare kan räkna med förändringarna återstår tester av release candidates, validering på riktig hårdvara och integrering i distributionerna.