Linux 7.3-netwerkmerge brengt BIG TCP naar overlays — en legt de AI-crisis bij maintainers bloot

De potentiële winst blijft bovendien niet beperkt tot systemen met een grotere MTU of speciale hardware voor tunnel-offloading. Ook bij een standaard-MTU en zonder hardwarematige tunnelondersteuning kan software intern minder, maar grotere pakketten verwerken.

Een ondersteunende patchreeks laat zien hoeveel onderliggend werk daarvoor nodig was. Verschillende tunnelpaden gingen er nog van uit dat pakketlengtes onder 64 KiB bleven of in 16-bits velden pasten. Die aannames zijn aangepast voor BIG TCP-verkeer over zowel VXLAN als Geneve, voor IPv4 en IPv6.

Minder globale RTNL-contentie bij FIB-regels

Een andere belangrijke wijziging vermindert de afhankelijkheid van de globale RTNL-lock bij FIB-rulebewerkingen, zoals RTM_NEWRULE en RTM_DELRULE. Dat is vooral relevant voor systemen die routeringsregels in veel network namespaces tegelijk beheren. Waar een globale serialisatie eerder de paralleliteit kon beperken, moet dit ontwerp meer gelijktijdige verwerking mogelijk maken.

De beschikbare informatie bevestigt het beoogde architecturale voordeel, maar bevat geen betrouwbare, precieze benchmarkcijfers voor IPv4- of IPv6-snelheidswinst. Een exact percentage of een concrete vermenigvuldigingsfactor zou daarom verder gaan dan het aangeleverde bewijs.

Nieuwe drivers en protocolverbeteringen

De netwerkpull bevat daarnaast een brede reeks hardware- en protocolupdates:

• De draadloze wijzigingen omvatten de Morse Micro mm81x-driver voor S1G-apparaten met groot bereik en een nieuwe NXPWIFI-driver.
• De voorlopige Intel iXD-infrastructuur richt zich op de Intel Control Plane PIC Function voor Intel E2100-en-latere IPU's en FNIC's.
• MPTCP gaat beter om met extreme geheugendruk en kan daarbij onder meer de out-of-order-ontvangstqueue opschonen.
• De bredere netwerkmerge bevat ook extra verbeteringen, bugfixes en driverwerk voor bedrade en draadloze netwerken.

Dit is code die tijdens de merge window-fase in de Linux 7.3-ontwikkeling is opgenomen. Het gaat dus nog niet om een voltooide stabiele Linux 7.3-release.

Waarom de maintainers zeggen dat ze “completely overwhelmed” zijn

Kicinski en Paolo Abeni melden dat ze 632 net-patches en 648 net-next-patches hebben gemerged: samen 1.280 patches. Dat aantal geeft volgens hen bovendien niet het volledige reviewwerk weer. Hun eigen “quick and dirty”-schatting is dat een derde tot de helft van de net-next-patches eruitzag als AI-gedreven fixes, opruimwerk of verduidelijkingen met lage prioriteit.

De druk past in een bredere stijging van het aantal inzendingen. In één periode van negen dagen kwamen 405 berichten binnen met de tag

[PATCH net]

[PATCH net-next]

Het probleem is dus niet alleen dat AI code kan schrijven. Met AI-hulp kunnen ook plausibele toelichtingen, bugmeldingen en verzoeken om review tegen zeer lage kosten worden geproduceerd. Voor menselijke maintainers blijft vervolgens de lastige taak over om per wijziging te bepalen of die noodzakelijk, correct, veilig en een merge waard is.

Hoe AI bij de review moet helpen

De maintainers zeggen dat ze dankzij financiering van Meta toegang en budget hebben geregeld voor meerdere grote taalmodellen. Die modellen moeten patches beoordelen en een deel van de hallucinaties of zwakke wijzigingen eruit filteren voordat ze extra menselijke reviewtijd kosten.

Daarnaast willen ze LLM's inzetten voor routinematig werk, waaronder:

• het beheren van Patchwork-wachtrijen;
• feedback geven op veelvoorkomende problemen in het indieningsproces;
• commitberichten redigeren; en
• mogelijk patches toepassen die al reviewtags van vertrouwde ontwikkelaars dragen.

Daarmee worden LLM's vooral workflow-assistenten, geen vervangers van subsystem-maintainers. Dat onderscheid is extra belangrijk bij kernelcode die gevoelig is voor concurrency. De maintainers wezen specifiek op zeldzame paden, zoals PCIe-fouten en time-outs, waarin timingafhankelijke races moeilijk zichtbaar te maken of definitief uit te sluiten zijn. LLM-review kan verdachte patronen signaleren, maar kan niet betrouwbaar bewijzen dat elke ongebruikelijke interleaving correct wordt afgehandeld.

Wat nog niet bekend is

De aangeleverde bronnen noemen geen verwachte datum voor Linux 7.3-rc1 of voor de uiteindelijke stabiele release. Ze beschrijven wijzigingen die tijdens de ontwikkelcyclus in mainline zijn opgenomen, niet een vastgestelde releaseplanning.

Ook voor de RTNL-aanpassingen ontbreekt een precieze IPv4- of IPv6-benchmark. De verdedigbare conclusie is daarom vooral architecturaal: minder afhankelijkheid van een globale lock moet workloads die in veel network namespaces tegelijk FIB-regels beheren meer schaalruimte geven, maar de concrete winst hangt af van de werklast en de systeemconfiguratie.