Linux 7.3 gir BIG TCP til VXLAN og Geneve – samtidig som utviklerne prøver AI i kodegjennomgangen

Linux 7.3 er fortsatt under utvikling, men nettverksendringene som ble slått sammen 20. august 2026 peker i to tydelige retninger: bedre ytelse i virtualiserte nettverk og et forsøk på å bruke AI til å håndtere den økende mengden kode som kommer inn. Dette er kode som er tatt inn i hovedtreet under sammenslåingsvinduet – ikke en ferdig, stabil Linux-versjon.

BIG TCP kommer til VXLAN og Geneve

Den mest synlige ytelsesendringen er at BIG TCP nå støttes av UDP-tunneldriverne for VXLAN og Geneve. BIG TCP gjør det mulig for kjernen å behandle nyttelaster større enn 64 KiB internt, før trafikken deles opp av GSO og TSO på vei ut til nettverket. Poenget er altså ikke å sende ulovlig store pakker over nettet, men å redusere arbeidet per pakke i dataprosesser som går gjennom nettverksoverlegg.

I de rapporterte

netperf TCP_STREAM

• VXLAN økte fra 34,44 til 39,56 Gbit/s, tilsvarende 14,9 prosent, med standard MTU.
• Med maskinvareavlasting for tunnelen deaktivert økte VXLAN fra 21,82 til 29,39 Gbit/s, eller 34,7 prosent.
• Geneve økte fra 37,39 til 40,89 Gbit/s, tilsvarende 9,4 prosent, med standard MTU.

Tallene bør likevel ikke tolkes som en generell ytelsesøkning for alle Linux 7.3-systemer. Resultatet avhenger blant annet av gso_max_size, gro_max_size, nettverkskortets egenskaper, avlastingsfunksjoner, MTU, tunneltype og arbeidsbelastning. Driftsansvarlige bør derfor måle sitt eget VXLAN- eller Geneve-oppsett før de forventer samme forbedring.

Mindre RTNL-låsing ved mange nettverksnavnerom

En annen viktig endring reduserer avhengigheten av den brede RTNL-låsen ved innsetting og sletting av IPv4- og IPv6-regler i FIB-en, altså videresendingsdatabasen. Der det er mulig, brukes det i stedet mutex-beskyttelse knyttet til den aktuelle fib_rules_ops. Det kan la flere operasjoner kjøre parallelt. RTNL er fortsatt nødvendig i enkelte tilfeller, blant annet i fib_unmerge()-banen for den første IPv4-regelen.

En syntetisk test viser hvor stor forskjellen kan bli under ekstrem belastning. Testen opprettet 4 096 nettverksnavnerom og la til 1 024 regler i hvert navnerom parallelt. For IPv4 falt tiden fra 22,752 til 0,918 sekunder, omtrent 24,8 ganger raskere. For IPv6 falt den fra 35,181 til 1,214 sekunder, omtrent 29,0 ganger raskere.

Dette må imidlertid ikke leses som et løfte om at alle containere starter 29 ganger raskere. Testen måler først og fremst effekten av kraftig låsekonkurranse i en svært parallell arbeidsbelastning.

Nettverksutviklerne er «helt overveldet» av AI-lapper

Sammenslåingen handler også om hvordan Linux-prosjektet skal håndtere stadig mer AI-generert kode. Nettverksansvarlig Jakub Kicinski oppga 632 net-lapper og 648 net-next-lapper, og anslo at mellom en tredel og halvparten av net-next besto av AI-drevne endringer med lav prioritet – for eksempel feilrettinger, opprydding og presiseringer. Det tilsvarer omtrent 216 til 324 lapper. Kicinski og Paolo Abeni beskrev arbeidsmengden som «helt overveldende».

Forslaget er ikke å overlate vedlikeholdet til én enkelt språkmodell. Meta har bidratt med budsjett og tilgang til flere avanserte AI-modeller, slik at oppdateringer kan få flere førstegangs gjennomganger. Målet er å redusere risikoen for at en hallusinasjon eller feilaktig tolkning fra én modell slipper gjennom uten å bli oppdaget.

Planlagt automatisering omfatter blant annet:

• håndtering av Patchwork,
• standardiserte tilbakemeldinger om prosessen,
• redigering av commit-meldinger,
• og muligens bruk av oppdateringer som allerede er vurdert av betrodde utviklere.

Dette er mer strukturerte oppgaver enn å avgjøre om en endring er korrekt i en sjelden feilsituasjon. Nettopp derfor understreker utviklerne at mennesker fortsatt må undersøke uvanlige kappløpstilstander og gjenopprettingsbaner, for eksempel håndtering av PCIe-feil og tidsavbrudd. AI kan sortere og effektivisere rutinearbeid, men erstatter ikke forståelse av samtidighet, API-kontrakter og rekkefølgen i feilhåndtering.

Nye drivere og protokollforbedringer

Nettverksoppdateringen inneholder også flere bidrag til maskinvare- og protokollstøtte:

• Den første driveren for Morse Micro mm81x støtter Wi-Fi HaLow-enheter via USB og SDIO.
• NXPWIFI kommer inn som en ny trådløs driver fra NXP, mens arbeidet med flerlenkedrift fortsetter.
• Intel får det første skjelettet til iXD-driveren, som skal støtte Control Plane PIC Function på IPU-er og FNIC-er fra E2100 og nyere.
• Kablet nettverk får innledende CXL-støtte for AMD/Solarflare-nettverkskort og støtte for fastvareoppdatering på AMD Pensando-maskinvare.

Det kommer også mindre, men praktiske endringer. MPTCP får en siste utvei for å rydde i køer med pakker som har kommet i feil rekkefølge når minnepresset blir ekstremt. Dette er først og fremst et tiltak for å unngå problemer under press, ikke en garanti for høyere normal gjennomstrømming.

I AF_UNIX blir det enklere å feilsøke overføring av fildeskriptorer. Med SO_RIGHTS_NOTRUNC kan mottakeren se hvilken fildeskriptor og hvilken errno som ble avvist når et Linux Security Module (LSM) blokkerer én fildeskriptor i en SCM_RIGHTS-liste. Dermed går ikke resten av listen tapt ved den første avvisningen.

Når kommer Linux 7.3?

Første utgivelseskandidat, 7.3-rc1, var ventet rundt 30. august 2026. Den stabile versjonen var anslått til slutten av oktober, forutsatt at utviklingssyklusen følger normal plan.

Det betyr ikke at de fleste servere og PC-er får disse nettverksfunksjonene i oktober. Linux-distribusjonene velger selv kjern versjoner, tilbakefører utvalgte endringer, tester dem og publiserer dem etter egne tidsplaner. Rullerende distribusjoner kan pakke inn Linux 7.3 relativt tidlig, mens distribusjoner med faste utgivelser kan bruke betydelig lengre tid.

CachyOS kan være blant de tidligere kandidatene fordi distribusjonen følger en rullerende modell. August-utgaven viste imidlertid fortsatt Linux 7.1, og kildene bekrefter ingen dato for når CachyOS eventuelt tar i bruk Linux 7.3.

Hva betyr dette i praksis?

For driftsteam er BIG TCP i VXLAN og Geneve samt mindre låsekonkurranse ved omfattende håndtering av nettverksnavnerom de mest umiddelbart interessante endringene. De er særlig relevante for miljøer som kombinerer nettverksoverlegg med høy trafikk, eller som oppretter og konfigurerer mange navnerom samtidig.

For Linux-utviklere kan AI-eksperimentet bli minst like viktig. Sammenslåingen antyder en arbeidsdeling: AI-modeller kan ta seg av repetitiv sortering og prosessarbeid, mens vedlikeholderne beholder ansvaret for de uvanlige tilfellene – der en tilsynelatende plausibel endring kan føre til vranglås, feilaktig gjenoppretting eller brudd på en uskreven synkroniseringsregel.

Linux 7.3 ser dermed ut til å få en omfattende nettverksoppdatering. Men før brukere kan stole på resultatene, gjenstår testing av utgivelseskandidater, validering på faktisk maskinvare og integrering i de enkelte distribusjonene.