Linux 7.3 bringt BIG TCP in VXLAN und Geneve, doch die Netzwerk-Maintainer sind überlastet

Eine ergänzende BIG-TCP-Patchserie beschreibt die dafür nötigen Anpassungen: Tunnelpfade durften nicht länger davon ausgehen, dass Paketlängen unter 64 KiB bleiben oder in 16-Bit-Felder passen. Die Serie umfasst BIG-TCP-Workloads für IPv4 und IPv6 über VXLAN und Geneve.

Weniger globale RTNL-Blockierung bei FIB-Regeln

Eine weitere wichtige Änderung reduziert die Abhängigkeit vom globalen RTNL-Lock bei Operationen an FIB-Regeln, etwa RTM_NEWRULE und RTM_DELRULE. Das zielt auf Systeme, die Routing-Regeln in vielen Netzwerk-Namespaces bearbeiten. Dort kann eine globale Serialisierung den möglichen Parallelismus ausbremsen.

Die Quellen belegen die angestrebte Verbesserung der Nebenläufigkeit, nennen aber keine belastbaren, präzisen IPv4- oder IPv6-Benchmarks. Konkrete Prozentwerte oder Beschleunigungsfaktoren wären daher nicht durch die vorliegenden Informationen gedeckt.

Neue Treiber und Protokollverbesserungen

Der Netzwerk-Merge erweitert außerdem die Hardware- und Protokollunterstützung:

• Im WLAN-Bereich kommen der Morse-Micro-Treiber mm81x für weitreichende S1G-Geräte sowie ein neuer NXPWIFI-Treiber hinzu.
• Die vorläufige Intel-iXD-Infrastruktur richtet sich an die Intel Control Plane PIC Function auf IPUs und FNICs ab Intel E2100.
• MPTCP verbessert sein Verhalten bei extremem Speicherdruck und kann unter anderem seine Out-of-Order-Empfangswarteschlange verkleinern.
• Der umfassendere Pull-Request enthält weitere Verbesserungen, Fehlerkorrekturen und Treiberarbeiten im kabelgebundenen und drahtlosen Netzwerk-Stack.

Diese Änderungen gehören zur Entwicklungsarbeit im Merge Window von Linux 7.3. Sie sind nicht mit einer bereits abgeschlossenen stabilen Linux-7.3-Veröffentlichung gleichzusetzen.

Warum die Maintainer von völliger Überlastung sprechen

Kicinski und Paolo Abeni meldeten, dass sie im Netzwerk-Pull 632 net-Patches und 648 net-next-Patches zusammengeführt hatten – insgesamt 1.280 Beiträge. Diese Zahl bilde die tatsächliche Review-Last noch nicht vollständig ab. Eine „schnelle und grobe“ Schätzung der Maintainer besagt, dass ein Drittel bis die Hälfte der net-next-Patches wie KI-getriebene, nachrangige Fixes, Aufräumarbeiten oder Klarstellungen wirkte.

Der Druck ist Teil eines breiteren Anstiegs bei den Einreichungen. Innerhalb eines Zeitraums von neun Tagen gingen 405 Beiträge mit dem Tag

[PATCH net]

[PATCH net-next]

Das Problem besteht nicht nur darin, dass KI Code erzeugen kann. KI-gestützte Entwickler können auch plausible Erklärungen, Fehlerberichte und Review-Anfragen zu sehr geringen Kosten produzieren. Die menschlichen Maintainer müssen trotzdem für jede Änderung prüfen, ob sie notwendig, korrekt, sicher und die Aufnahme in den Kernel überhaupt wert ist.

So soll KI künftig beim Review helfen

Die Maintainer berichten, dass sie dank von Meta finanzierter Zugänge und Budgets mehrere große Sprachmodelle zur Prüfung von Patches einsetzen können. Zunächst sollen die Modelle dabei helfen, halluzinierte oder schwache Änderungen abzufangen, bevor sie noch mehr Zeit im menschlichen Review binden.

Außerdem sollen die Modelle stärker Routineaufgaben im Entwicklungsprozess übernehmen, darunter:

• die Verwaltung von Patchwork-Warteschlangen;
• Hinweise auf häufige Probleme beim Einreichungsprozess;
• das Bearbeiten von Commit-Nachrichten; und
• möglicherweise das Anwenden von Patches, die bereits vertrauenswürdige Review-Tags tragen.

Damit werden LLMs als Workflow-Helfer eingesetzt – nicht als Ersatz für die Maintainer eines Subsystems. Dieser Unterschied ist bei nebenläufigkeitskritischem Kernel-Code besonders wichtig. Die Maintainer verwiesen ausdrücklich auf seltene Ereignispfade wie PCIe-Fehler und Timeouts. Dort können timingabhängige Race Conditions schwer zu reproduzieren oder mit letzter Sicherheit auszuschließen sein. Ein LLM-Review kann verdächtige Muster aufdecken, aber nicht zuverlässig die Korrektheit jeder ungewöhnlichen Interleaving-Situation beweisen.

Was weiterhin offen ist

Die vorliegenden Berichte nennen keine verlässlichen Termine für

Linux 7.3-rc1

Auch für die RTNL-Änderungen gibt es keine belastbare konkrete Leistungszahl für IPv4 oder IPv6. Die vorsichtige Schlussfolgerung lautet: Weniger globale Lock-Konkurrenz sollte stark parallelisierten Workloads bei der Verwaltung vieler Netzwerk-Namespaces mehr Skalierungsspielraum geben. Wie groß der Effekt tatsächlich ausfällt, hängt jedoch vom jeweiligen Workload und der Systemkonfiguration ab.