Linux mainline merged net-next-7.3 on August 20, 2026. At its center are changes that reduce dependency on RTNL—a global lock—for routing rule updates, and changes that extend BIG TCP to the UDP tunnels VXLAN and Geneve. The former targets scenarios that manipulate many network namespaces simultaneously, while the latter targets data paths that pass through overlays. The official release of Linux 7.3 has not yet been published; this is code that entered mainline during the merge window stage. When reading the performance figures, one must distinguish which lock was removed from which tunnel and configuration was used for measurement.
Parallelizing FIB Updates Across 4,096 Namespaces
The FIB (Forwarding Information Base) rule operations RTM_NEWRULE and RTM_DELRULE moved to a structure protected by a mutex held by each fib_rules_ops. Previously, rule operations on independent network namespaces could be serialized under RTNL, which broadly protects network device configuration. Even after this change, RTNL is still required when executing fib_unmerge() on the first IPv4 rule. RTNL has not been uniformly eliminated.
The developer who submitted the change presented a synthetic benchmark that created 4,096 network namespaces and inserted 1,024 rules into each in parallel. IPv4 wall-clock time dropped from 22.752 seconds to 0.918 seconds, a calculated 24.8x improvement. IPv6 dropped from 35.181 seconds to 1.214 seconds, a 29.0x improvement. The series description rounds these to approximately 20x for IPv4 and 30x for IPv6.
What this benchmark captures is the load of many independent namespaces waiting on the same global lock. It does not show that ordinary container startup will speed up by the same 25-29x. Still, the mechanism change is clear: rule operations that can be handled independently per namespace are now less likely to be unnecessarily serialized by RTNL.
BIG TCP Extends to VXLAN and Geneve
BIG TCP is a mechanism that handles chunks larger than 64KiB inside the network stack, splitting them into transmittable segments via Generic Segmentation Offload (GSO) or TCP Segmentation Offload (TSO) before sending. It is not a feature that sends giant packets as-is over the physical network. Previously, when using Cilium, the BIG TCP path was limited to direct routing, but this update enables the over-64KiB TSO/GRO path for the UDP overlays VXLAN and Geneve as well.
Both the VXLAN and Geneve changes were measured with netperf TCP_STREAM in the author's own environment. VXLAN also includes a separate condition with all hardware tunnel offload disabled.
| Tunnel and condition | Before | After | Calculated difference |
|---|---|---|---|
| VXLAN, standard MTU | 34,440.00 Mbit/s | 39,564.78 Mbit/s | +14.9% |
| VXLAN, 8k MTU | 55,684.26 Mbit/s | 61,466.47 Mbit/s | +10.4% |
| VXLAN, hardware tunnel offload disabled | 21,820.82 Mbit/s | 29,390.78 Mbit/s | +34.7% |
| Geneve, standard MTU | 37,391.34 Mbit/s | 40,891.57 Mbit/s | +9.4% |
| Geneve, 8k MTU | 58,030.19 Mbit/s | 61,458.39 Mbit/s | +5.9% |
These differences in the table are not overall performance improvement rates for Linux 7.3 as a whole. To use BIG TCP, administrators must properly configure settings such as gso_max_size and gro_max_size, and the entire path must support it. Results will also vary with NIC, tunnel offload, MTU, and traffic patterns, so in practice this needs to be verified with the specific CNI and NIC combination being used.
Recovery and Error Reporting Changes, Separate from Speed
MPTCP (Multipath TCP) received a change that prunes the out-of-order queue as a last resort under extreme memory pressure. The target is the queue at the MPTCP layer, and this is a measure meant to speed up retransmission and recovery. It should not be read as an update showing normal-state throughput, but rather as a change that provides a path toward recovery under severe memory conditions.
An update was also added to AF_UNIX's SCM_RIGHTS reception that changes how failures are reported. When Linux Security Modules (LSM) reject some file descriptors, enabling SO_RIGHTS_NOTRUNC prevents the array from being truncated at the first rejection point. Since each slot is preserved and the LSM's errno can be placed at the rejected position, the receiving side can determine which file descriptor was rejected.
Unlike fast-path changes such as BIG TCP, these changes target behavior under abnormal conditions. They make explicit which queue to discard under memory pressure and how to report LSM rejections back to the receiver, reducing the information lost during recovery and error handling.
mm81x Opens a Mainline Entry Point for Wi-Fi HaLow
Morse Micro's mm81x Wi-Fi HaLow driver has also entered mainline. Supporting both USB and SDIO, it serves as an entry point for using Wi-Fi HaLow—the sub-1GHz IEEE 802.11ah family—for long-range, low-power IoT applications. It reduces dependency on vendor-specific out-of-tree modules.
However, the initial implementation is limited to station mode, access point mode, and basic functionality. Regional support is also limited, so this is not yet a state where all Wi-Fi HaLow features, all regions, and all products can be used immediately. The same batch of updates also includes a new nxpwifi driver, an initial CXL implementation for AMD/Solarflare NICs, and driver skeletons for Intel iXD and ZTE Dinghai. This is an update that expands coverage into mainline while making clear that it remains at an early stage.
Linux 7.2's networking updates centered on device, standard, and hardware support such as Wi-Fi Aware, UHR, and RTL8159. In the 7.3 batch, the emphasis has shifted toward overlay data paths, control-plane parallelism, and handling of abnormal conditions.
Why Multiple LLMs Review Patches
Jakub Kicinski presented rough figures showing that he and Paolo Abeni merged 632 patches into net and 648 into net-next. net is the tree that collects fixes for the current release, while net-next collects new code for future releases. These two numbers do not share the same denominator as the total commit count included in mainline merge tags.
Kicinski also estimated that one-third to one-half of net-next consists of low-priority fixes, cleanups, and description improvements that appear to originate from AI. This is not an audited count, nor a figure that uniformly evaluates all AI-originated patches.
With support from Meta, the maintainer team has secured a usage allocation to review each patch with multiple state-of-the-art models. At the same time, Kicinski also stated that for low-frequency events such as PCIe errors and timeouts, API issues involving race conditions cannot be solved by LLMs alone. In the next cycle, the policy is to shift work such as patchwork management, routine procedural comments, and commit message editing to LLMs.
From 7.3-rc1 onward, how well this settles in will depend on how the BIG TCP tunnel paths are verified across different CNI and NIC combinations, whether the FIB changes regress under parallel workloads, and how human review handles low-frequency error paths.