BIG TCP går gjennom VXLAN og Geneve

BIG TCP støttes nå gjennom UDP-baserte overlay-tunneler i VXLAN- og Geneve-driverne. Overlay-nettverk brukes blant annet til å frakte virtuell trafikk mellom fysiske verter og svitsjer.

Endringen gjør at Linux kan håndtere nyttelaster større enn 64 KiB internt i nettverksstakken. Før trafikken sendes på kabelen, deles den opp gjennom GSO/TSO – funksjoner som samler eller segmenterer pakker i programvare og maskinvare – i stedet for at enorme pakker sendes direkte over nettet.

De rapporterte netperf TCP_STREAM-målingene viste følgende:

• VXLAN økte fra 34,44 til 39,56 Gbit/s, tilsvarende 14,9 prosent, ved standard MTU.
• Med maskinvareavlasting for tunnel 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, ved standard MTU.

Tallene er konfigurasjonsspesifikke resultater, ikke et løfte om at alle Linux 7.3-systemer blir tilsvarende raskere. Gevinsten avhenger blant annet av gso_max_size og gro_max_size, nettverkskortets egenskaper, MTU, tunneltypen, statusen for avlasting og selve arbeidsbelastningen.

Mindre RTNL-konkurranse ved mange rutingendringer

En annen sentral endring gjelder FIB-regler – regler i Forwarding Information Base som avgjør hvordan IPv4- og IPv6-trafikk skal rutes. Operasjonene for å legge til og slette slike regler flyttes i større grad bort fra den brede RTNL-serialiseringen.

RTNL er en global lås som beskytter mange nettverksendringer i kjernen. Den er fortsatt nødvendig i enkelte tilfeller, blant annet gjennom fib_unmerge()-banen for den første IPv4-regelen, men de nye endringene bruker i større grad mutex-beskyttelse per fib_rules_ops der det er mulig.

I en syntetisk test ble 4 096 nettverksnavnerom opprettet, og 1 024 regler ble satt inn i hvert navnerom parallelt. Tiden for IPv4-operasjonene falt fra 22,752 til 0,918 sekunder, omtrent 24,8 ganger raskere. For IPv6 falt tiden fra 35,181 til 1,214 sekunder, rundt 29 ganger raskere.

Dette er en ekstrem test av parallell konkurranse mellom mange navnerom, ikke en direkte måling av hvor mye raskere vanlig oppstart av containere blir.

Vedlikeholderne vil bruke AI til å håndtere patchmengden

Jakub Kicinski, en av nettverksvedlikeholderne, oppga 632 net-patcher og 648 net-next-patcher. Han anslo samtidig at mellom en tredel og halvparten av net-next besto av AI-drevne feilrettinger, oppryddinger eller presiseringer med lav prioritet – omtrent 216 til 324 patcher. Kicinski og Paolo Abeni beskrev situasjonen som at de var «fullstendig overveldet».

Meta har bidratt med budsjett og tilgang til flere avanserte AI-modeller som kan gjennomføre en første gjennomgang av hver patch. Tanken er at flere modeller kan redusere risikoen for at én enkelt modell overser problemer eller finner på feilaktige innvendinger.

Den planlagte automatiseringen kan blant annet brukes til å administrere Patchwork, gi tilbakemeldinger på vanlige prosessfeil, redigere commit-meldinger og i enkelte tilfeller legge inn patcher som allerede er gjennomgått av betrodde utviklere.

Men vedlikeholderne understreker at dette ikke er nok for sjeldne og konkurranseutsatte kodebaner. Problemer rundt PCIe-feil, tidsavbrudd og maskinvaregjenoppretting kan avhenge av detaljert API-forståelse og riktig rekkefølge på gjenopprettingssteg – områder der menneskelig vurdering fortsatt er avgjørende.

Flere drivere og protokollendringer

Innslippingen inneholder også en rekke andre nettverksrelaterte oppdateringer:

• Trådløsnettverk får den første Morse Micro mm81x-driveren for Wi‑Fi HaLow-enheter via USB og SDIO, i tillegg til den nye NXPWIFI-driveren for NXP-utstyr. Arbeidet med MLO fortsetter også.
• På kablet side kommer det første skjelettet til Intel iXD, som skal brukes til støtte for Intel Control Plane PIC Function på E2100- og nyere IPU-er/FNIC-er.
• Det kommer innledende CXL-støtte for AMD- og Solarflare-nettverkskort samt støtte for fastvareblinking på AMD Pensando-kort.
• MPTCP får en mekanisme som i siste instans kan rydde i køen for pakker som kommer i feil rekkefølge under ekstremt minnepress. Dette er først og fremst en gjenopprettings- og retransmisjonsmekanisme, ikke en vanlig ytelsesfunksjon.
• AF_UNIX med SCM_RIGHTS gir bedre rapportering når et Linux Security Module-system avviser bestemte fildeskriptorer. Med SO_RIGHTS_NOTRUNC kan mottakeren identifisere hvilken fildeskriptor som ble avvist, og få tilhørende errno, i stedet for at resten av arrayet går tapt ved første feil.

Når kommer Linux 7.3?

Den første 7.3-utgivelseskandidaten var ventet rundt 30. august, mens en stabil utgave var anslått til slutten av oktober, forutsatt et normalt utviklingsløp.

Brukere av distribusjoner med faste utgivelsessykluser må likevel regne med å vente lenger. Distribusjonene velger, tilbakeporterer, tester og publiserer kjerner etter egne tidsplaner. Rullende distribusjoner kan ta inn Linux 7.3 tidligere.

CachyOS kan være blant de tidlige kandidatene, men kildene dokumenterer ingen bindende dato for 7.3-støtte. August-avbildningen brukte fortsatt Linux 7.1.

BIG TCP går gjennom VXLAN og Geneve

BIG TCP støttes nå gjennom UDP-baserte overlay-tunneler i VXLAN- og Geneve-driverne. Overlay-nettverk brukes blant annet til å frakte virtuell trafikk mellom fysiske verter og svitsjer.

Endringen gjør at Linux kan håndtere nyttelaster større enn 64 KiB internt i nettverksstakken. Før trafikken sendes på kabelen, deles den opp gjennom GSO/TSO – funksjoner som samler eller segmenterer pakker i programvare og maskinvare – i stedet for at enorme pakker sendes direkte over nettet.

De rapporterte netperf TCP_STREAM-målingene viste følgende:

• VXLAN økte fra 34,44 til 39,56 Gbit/s, tilsvarende 14,9 prosent, ved standard MTU.
• Med maskinvareavlasting for tunnel 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, ved standard MTU.

Tallene er konfigurasjonsspesifikke resultater, ikke et løfte om at alle Linux 7.3-systemer blir tilsvarende raskere. Gevinsten avhenger blant annet av gso_max_size og gro_max_size, nettverkskortets egenskaper, MTU, tunneltypen, statusen for avlasting og selve arbeidsbelastningen.

Mindre RTNL-konkurranse ved mange rutingendringer

En annen sentral endring gjelder FIB-regler – regler i Forwarding Information Base som avgjør hvordan IPv4- og IPv6-trafikk skal rutes. Operasjonene for å legge til og slette slike regler flyttes i større grad bort fra den brede RTNL-serialiseringen.

RTNL er en global lås som beskytter mange nettverksendringer i kjernen. Den er fortsatt nødvendig i enkelte tilfeller, blant annet gjennom fib_unmerge()-banen for den første IPv4-regelen, men de nye endringene bruker i større grad mutex-beskyttelse per fib_rules_ops der det er mulig.

I en syntetisk test ble 4 096 nettverksnavnerom opprettet, og 1 024 regler ble satt inn i hvert navnerom parallelt. Tiden for IPv4-operasjonene falt fra 22,752 til 0,918 sekunder, omtrent 24,8 ganger raskere. For IPv6 falt tiden fra 35,181 til 1,214 sekunder, rundt 29 ganger raskere.

Dette er en ekstrem test av parallell konkurranse mellom mange navnerom, ikke en direkte måling av hvor mye raskere vanlig oppstart av containere blir.

Vedlikeholderne vil bruke AI til å håndtere patchmengden

Jakub Kicinski, en av nettverksvedlikeholderne, oppga 632 net-patcher og 648 net-next-patcher. Han anslo samtidig at mellom en tredel og halvparten av net-next besto av AI-drevne feilrettinger, oppryddinger eller presiseringer med lav prioritet – omtrent 216 til 324 patcher. Kicinski og Paolo Abeni beskrev situasjonen som at de var «fullstendig overveldet».

Meta har bidratt med budsjett og tilgang til flere avanserte AI-modeller som kan gjennomføre en første gjennomgang av hver patch. Tanken er at flere modeller kan redusere risikoen for at én enkelt modell overser problemer eller finner på feilaktige innvendinger.

Den planlagte automatiseringen kan blant annet brukes til å administrere Patchwork, gi tilbakemeldinger på vanlige prosessfeil, redigere commit-meldinger og i enkelte tilfeller legge inn patcher som allerede er gjennomgått av betrodde utviklere.

Men vedlikeholderne understreker at dette ikke er nok for sjeldne og konkurranseutsatte kodebaner. Problemer rundt PCIe-feil, tidsavbrudd og maskinvaregjenoppretting kan avhenge av detaljert API-forståelse og riktig rekkefølge på gjenopprettingssteg – områder der menneskelig vurdering fortsatt er avgjørende.

Flere drivere og protokollendringer

Innslippingen inneholder også en rekke andre nettverksrelaterte oppdateringer:

• Trådløsnettverk får den første Morse Micro mm81x-driveren for Wi‑Fi HaLow-enheter via USB og SDIO, i tillegg til den nye NXPWIFI-driveren for NXP-utstyr. Arbeidet med MLO fortsetter også.
• På kablet side kommer det første skjelettet til Intel iXD, som skal brukes til støtte for Intel Control Plane PIC Function på E2100- og nyere IPU-er/FNIC-er.
• Det kommer innledende CXL-støtte for AMD- og Solarflare-nettverkskort samt støtte for fastvareblinking på AMD Pensando-kort.
• MPTCP får en mekanisme som i siste instans kan rydde i køen for pakker som kommer i feil rekkefølge under ekstremt minnepress. Dette er først og fremst en gjenopprettings- og retransmisjonsmekanisme, ikke en vanlig ytelsesfunksjon.
• AF_UNIX med SCM_RIGHTS gir bedre rapportering når et Linux Security Module-system avviser bestemte fildeskriptorer. Med SO_RIGHTS_NOTRUNC kan mottakeren identifisere hvilken fildeskriptor som ble avvist, og få tilhørende errno, i stedet for at resten av arrayet går tapt ved første feil.

Når kommer Linux 7.3?

Den første 7.3-utgivelseskandidaten var ventet rundt 30. august, mens en stabil utgave var anslått til slutten av oktober, forutsatt et normalt utviklingsløp.

Brukere av distribusjoner med faste utgivelsessykluser må likevel regne med å vente lenger. Distribusjonene velger, tilbakeporterer, tester og publiserer kjerner etter egne tidsplaner. Rullende distribusjoner kan ta inn Linux 7.3 tidligere.

CachyOS kan være blant de tidlige kandidatene, men kildene dokumenterer ingen bindende dato for 7.3-støtte. August-avbildningen brukte fortsatt Linux 7.1.