Linux 7.3 bringt mehr Tempo für Overlay-Netze – und stellt die Kernel-Entwickler vor ein KI-Problem

Der Netzwerk-Merge für Linux 7.3 ist aus zwei sehr unterschiedlichen Gründen bemerkenswert: Er soll Overlay- und Namespace-lastige Workloads besser skalieren – und zeigt zugleich, wie die Kernel-Entwickler auf die wachsende Zahl KI-generierter Patches reagieren. Der Code wurde am 20. August 2026 während des Merge-Fensters in den Mainline-Kernel aufgenommen. Linux 7.3 ist damit noch keine stabile Veröffentlichung.

BIG TCP erreicht VXLAN und Geneve

Linux 7.3 erweitert BIG TCP auf die UDP-Tunnel-Treiber für VXLAN und Geneve. Der Kernel kann Nutzdaten damit intern größer als 64 KiB verarbeiten und sie anschließend über GSO und TSO segmentieren, bevor sie tatsächlich über das Netzwerk übertragen werden. Es geht also nicht darum, übergroße Pakete auf das Kabel zu schicken, sondern den Paketverarbeitungsaufwand in Overlay-Datenpfaden zu verringern.

Die gemeldeten

netperf TCP_STREAM

• Bei VXLAN stieg der Durchsatz mit Standard-MTU von 34,44 auf 39,56 Gbit/s – ein Plus von 14,9 Prozent.
• Bei deaktiviertem Hardware-Offload für den Tunnel erhöhte sich VXLAN von 21,82 auf 29,39 Gbit/s, also um 34,7 Prozent.
• Geneve legte mit Standard-MTU von 37,39 auf 40,89 Gbit/s zu – ein Plus von 9,4 Prozent.

Diese Werte gelten nur für die jeweils getestete Konfiguration. Entscheidend sind unter anderem gso_max_size, gro_max_size, die Fähigkeiten der Netzwerkkarte, aktivierte Offload-Funktionen, MTU, Tunneltyp und Workload. Betreiber sollten ihre eigenen VXLAN- oder Geneve-Pfade messen, statt die Prozentsätze als pauschalen Linux-7.3-Speedup zu verstehen.

Weniger RTNL-Blockierung beim Ändern von Routing-Regeln

Eine zweite wichtige Änderung betrifft das Hinzufügen und Löschen von IPv4- und IPv6-FIB-Regeln. Diese Vorgänge sind nun, soweit möglich, weniger stark vom breit wirkenden RTNL-Lock abhängig. Stattdessen kommt ein Mutex zum Einsatz, der den jeweiligen fib_rules_ops zugeordnet ist. Dadurch können mehrere Vorgänge parallel ablaufen. In bestimmten Fällen bleibt RTNL allerdings erforderlich, etwa beim fib_unmerge()-Pfad der ersten IPv4-Regel.

Ein synthetischer Test mit starkem Parallelismus verdeutlicht den möglichen Effekt. Dabei wurden 4.096 Netzwerk-Namespaces angelegt und jeweils 1.024 Regeln parallel hinzugefügt:

• IPv4: von 22,752 auf 0,918 Sekunden, etwa 24,8-mal schneller
• IPv6: von 35,181 auf 1,214 Sekunden, etwa 29,0-mal schneller

Die Zahlen messen vor allem extreme Lock-Konkurrenz bei der Verwaltung vieler Namespaces. Sie sind kein Versprechen, dass jeder Containerstart oder jeder Routing-Workload in diesem Maß beschleunigt wird.

Warum KI bei der Patch-Sichtung helfen soll

Der Netzwerk-Teil des Kernels wird außerdem zu einem Testfeld für KI-gestützte Entwicklungsprozesse. Jakub Kicinski nannte 632 Patches im Bereich net und 648 Patches in net-next. Seiner Einschätzung zufolge bestand etwa ein Drittel bis die Hälfte von net-next aus KI-getriebenen, niedrig priorisierten Korrekturen, Aufräumarbeiten oder Klarstellungen – rechnerisch ungefähr 216 bis 324 Patches. Kicinski und Paolo Abeni beschrieben die daraus entstehende Arbeitslast als „completely overwhelmed“, also völlig überlastet.

Die geplante Antwort besteht nicht darin, die Maintainer durch ein einzelnes Modell zu ersetzen. Meta stellt Budget und Zugang zu mehreren fortschrittlichen KI-Modellen bereit. Eingehende Patches sollen dadurch zunächst von mehreren Modellen geprüft werden, damit eine Halluzination oder Fehlinterpretation eines einzelnen Systems nicht unbemerkt den weiteren Prozess bestimmt.

Automatisiert werden könnten zunächst vergleichsweise strukturierte Aufgaben:

• die Verwaltung in Patchwork,
• standardisierte Rückmeldungen zum Entwicklungsprozess,
• die Überarbeitung von Commit-Nachrichten,
• möglicherweise auch das Anwenden von Patches, die bereits von vertrauenswürdigen Personen geprüft wurden.

Die Grenzen liegen dort, wo eine Änderung nur in seltenen Situationen problematisch wird. Ungewöhnliche Race Conditions sowie Hardware-Recovery-Pfade – etwa bei PCIe-Fehlern oder Timeouts – benötigen weiterhin menschliche Expertise. KI kann wiederkehrende Sichtungsarbeit filtern, ersetzt aber nicht das Verständnis von Nebenläufigkeit, API-Verträgen und der korrekten Reihenfolge von Wiederherstellungsschritten.

Neue Treiber und weitere Netzwerkänderungen

Der Merge bringt neben den Kernverbesserungen auch neue Hardware-Unterstützung:

• Der erste Morse-Micro-mm81x-Treiber für Wi-Fi HaLow unterstützt USB- und SDIO-Geräte.
• Mit NXPWIFI kommt ein neuer WLAN-Treiber für NXP-Hardware hinzu; die Arbeit an Multi-Link Operation läuft weiter.
• Intel erhält das grundlegende Gerüst des iXD-Treibers für Control Plane PIC Function auf IPUs und FNICs ab der E2100-Generation.
• Für kabelgebundene Netzwerke gibt es erste CXL-Unterstützung für AMD-/Solarflare-NICs sowie Unterstützung zum Flashen von Firmware auf AMD-Pensando-Hardware.

Auch bei bestehenden Protokollen gibt es kleinere, aber praxisrelevante Anpassungen. MPTCP erhält unter extremem Speicherdruck einen Notfallmechanismus, der Out-of-Order-Warteschlangen verkleinern kann. Das ist vor allem eine Maßnahme zur Stabilisierung unter knappen Ressourcen und kein Versprechen auf höheren normalen Durchsatz.

Die Übergabe von Dateideskriptoren über AF_UNIX wird ebenfalls besser diagnostizierbar. Mit SO_RIGHTS_NOTRUNC kann der Empfänger erkennen, welcher Dateideskriptor abgelehnt wurde und welcher errno-Wert vorlag, wenn ein Linux Security Module (LSM) einen Eintrag in einem SCM_RIGHTS-Array blockiert. Die übrigen Einträge gehen dann nicht mehr automatisch beim ersten Fehler verloren.

Wann kommt Linux 7.3 bei den Nutzern an?

Der erste Release Candidate wurde für ungefähr den 30. August 2026 erwartet. Die stabile Veröffentlichung war – bei normalem Verlauf des Entwicklungszyklus – für Ende Oktober prognostiziert.

Das bedeutet allerdings nicht, dass die meisten Server und Desktop-Systeme im Oktober automatisch diese Netzwerkfunktionen erhalten. Distributionen wählen ihre Kernel-Versionen selbst, übernehmen einzelne Änderungen zurück in ältere Kernel, testen sie separat und veröffentlichen sie nach eigenen Zeitplänen. Rolling Releases können Linux 7.3 früher anbieten, während feste Distributionsversionen deutlich länger warten können.

CachyOS wäre wegen seines Rolling-Modells ein naheliegender früher Nutzer. Die verfügbaren August-Images liefen jedoch noch mit Linux 7.1 und bestätigen keinen konkreten Termin für eine Umstellung auf Linux 7.3.

Was der Merge in der Praxis bedeutet

Für Infrastruktur-Teams sind vor allem zwei Änderungen interessant: der BIG-TCP-Pfad durch VXLAN und Geneve sowie die geringere Konkurrenz beim parallelen Verwalten von Routing-Regeln in vielen Netzwerk-Namespaces. Besonders aufmerksam sollten Betreiber von Umgebungen mit hohem Overlay-Durchsatz und Plattformen sein, die viele Namespaces gleichzeitig erzeugen und konfigurieren.

Für Kernel-Entwickler könnte das KI-Experiment langfristig ebenso wichtig sein. Der Merge deutet auf eine klare Arbeitsteilung hin: Modelle übernehmen repetitive Sichtungs- und Prozessaufgaben, während Maintainer die Verantwortung für seltene Fälle behalten, in denen ein plausibel wirkender Patch ein Deadlock-Risiko birgt, die Wiederherstellung nach einem Hardwarefehler beschädigt oder eine implizite Synchronisationsregel verletzt.

Linux 7.3 erhält damit ein umfangreiches Netzwerkpaket. Bevor die Änderungen für die breite Nutzung relevant werden, stehen jedoch noch Tests mit Release Candidates, Hardware-Validierung und die Integration durch die einzelnen Distributionen aus.