从已公布的 netperf TCP_STREAM 测试来看，这项变化在特定配置下确实带来了明显收益：

• 在标准 MTU 下，VXLAN 吞吐量从 34.44 Gbit/s 提升到 39.56 Gbit/s，增幅约 14.9%。
• 禁用隧道硬件卸载后，VXLAN 吞吐量从 21.82 Gbit/s 提升到 29.39 Gbit/s，增幅约 34.7%。
• 在标准 MTU 下，Geneve 吞吐量从 37.39 Gbit/s 提升到 40.89 Gbit/s，增幅约 9.4%。

不过，这些数字不能理解为 Linux 7.3 在所有环境中的统一性能提升。实际效果会受到端到端配置影响，包括 gso_max_size、gro_max_size、网卡能力、卸载功能开关、MTU、隧道类型以及具体工作负载。使用 VXLAN 或 Geneve 的运维团队仍应先在自己的链路上进行基准测试。

路由规则更新减少 RTNL 锁竞争

本次合并还减少了 IPv4 和 IPv6 FIB 规则插入、删除操作对广泛 RTNL 锁的依赖。在可能的情况下，相关操作改用与对应 fib_rules_ops 关联的互斥锁保护，从而让更多操作能够并行执行。某些路径仍然需要 RTNL，例如第一个 IPv4 规则的 fib_unmerge() 路径。

一项合成测试展示了这项改动在大规模网络命名空间管理中的潜力：并行创建 4,096 个网络命名空间，并为每个命名空间添加 1,024 条规则时：

• IPv4 用时从 22.752 秒降至 0.918 秒，约提升 24.8 倍；
• IPv6 用时从 35.181 秒降至 1.214 秒，约提升 29.0 倍。

这组数据反映的是极端锁竞争场景，并不意味着普通容器启动或所有路由工作负载都会获得同等幅度的加速。

AI 补丁太多，维护者开始寻找新的分流方式

Linux 网络子系统的另一项变化，来自开发流程本身。网络维护者 Jakub Kicinski 表示，当前统计中有 632 个 net 补丁和 648 个 net-next 补丁。他估计，net-next 中约有三分之一至二分之一是由 AI 驱动产生的低优先级修复、清理或说明性修改，折算下来约为 216 至 324 个补丁。Kicinski 和 Paolo Abeni 形容由此带来的工作量已经“完全不堪重负”。

提出的解决方案并不是让某一个模型取代维护者。Meta 提供了预算和多个前沿模型的使用权限，让补丁先接受多模型初步审查，以降低单个模型产生幻觉或误判后直接影响开发流程的风险。

计划中的自动化工作包括：

• 管理 Patchwork 中的补丁状态；
• 提供常规流程反馈；
• 修改提交信息；
• 在可信人员已经审查过的前提下，考虑自动应用部分补丁。

这些工作相对结构化，适合用来减少重复性劳动。但它们与判断一个补丁是否会在罕见故障路径中出错，是两类不同的问题。

内核网络代码涉及并发、API 契约和故障恢复顺序。维护者特别指出，罕见竞态以及 PCIe 错误、超时处理等硬件恢复路径，仍然需要人类仔细审查。AI 可以帮助过滤重复工作，却不能消除对同步规则和恢复逻辑的理解要求。

新驱动与协议改进

本次网络合并还包含多项硬件支持和协议改进：

• 初步加入 Morse Micro mm81x Wi-Fi HaLow 驱动，支持 USB 和 SDIO 设备；
• 新增 NXPWIFI 无线驱动，NXP 多链路操作相关工作仍在继续；
• Intel 获得初版 iXD 驱动框架，用于支持 E2100 及后续 IPU 和 FNIC 上的 Control Plane PIC Function；
• 有线网络加入 AMD/Solarflare 网卡的初步 CXL 支持，并支持为 AMD Pensando 硬件刷写固件。

此外，MPTCP 在极端内存压力下新增了最后手段：清理乱序队列。这是面向内存受限条件的恢复措施，并不代表日常传输吞吐量一定会提高。

AF_UNIX 的文件描述符传递也更容易排查问题。启用 SO_RIGHTS_NOTRUNC 后，如果 LSM 在 SCM_RIGHTS 数组中拒绝某个文件描述符，接收方可以识别具体被拒绝的描述符及其 errno，而不必在遇到第一个拒绝后丢失数组中的其余内容。

Linux 7.3 什么时候发布？

按照目前的开发节奏，Linux 7.3 的首个候选版本预计在 2026 年 8 月 30 日左右出现，稳定版预计在 10 月下旬发布，但具体时间仍取决于正常的发布周期。

这并不意味着大多数服务器和桌面系统会在 10 月立即获得这些网络功能。各 Linux 发行版会自行选择内核版本、回移部分改动、完成测试并安排发布。滚动更新发行版可能更早打包，而固定版本发行版通常需要明显更长时间。

CachyOS 由于采用滚动更新模式，理论上可能成为较早采用者之一。不过，现有的 8 月版本信息显示，其安装镜像仍使用 Linux 7.1，并未确认 Linux 7.3 的具体采用日期。

这次合并对用户意味着什么？

对基础设施团队而言，最值得关注的是 BIG TCP 对 VXLAN/Geneve 覆盖路径的支持，以及大规模并行管理网络命名空间时锁竞争的下降。两者尤其适合在高吞吐覆盖网络，或需要同时创建、配置大量命名空间的环境中进行验证。

对内核开发者而言，AI 审查试验可能同样重要。此次合并展现出一种更现实的分工：模型负责吸收重复性的补丁分流和流程反馈，维护者则继续把精力集中在那些表面上合理、却可能导致死锁、错误处理硬件恢复或破坏隐含同步规则的少见场景上。

因此，Linux 7.3 正带着一组相当可观的网络功能进入后续开发阶段。但在大多数用户能够依赖这些改动之前，它仍需要经过候选版本测试、硬件验证和各发行版的集成。

从已公布的 netperf TCP_STREAM 测试来看，这项变化在特定配置下确实带来了明显收益：

• 在标准 MTU 下，VXLAN 吞吐量从 34.44 Gbit/s 提升到 39.56 Gbit/s，增幅约 14.9%。
• 禁用隧道硬件卸载后，VXLAN 吞吐量从 21.82 Gbit/s 提升到 29.39 Gbit/s，增幅约 34.7%。
• 在标准 MTU 下，Geneve 吞吐量从 37.39 Gbit/s 提升到 40.89 Gbit/s，增幅约 9.4%。

不过，这些数字不能理解为 Linux 7.3 在所有环境中的统一性能提升。实际效果会受到端到端配置影响，包括 gso_max_size、gro_max_size、网卡能力、卸载功能开关、MTU、隧道类型以及具体工作负载。使用 VXLAN 或 Geneve 的运维团队仍应先在自己的链路上进行基准测试。

路由规则更新减少 RTNL 锁竞争

本次合并还减少了 IPv4 和 IPv6 FIB 规则插入、删除操作对广泛 RTNL 锁的依赖。在可能的情况下，相关操作改用与对应 fib_rules_ops 关联的互斥锁保护，从而让更多操作能够并行执行。某些路径仍然需要 RTNL，例如第一个 IPv4 规则的 fib_unmerge() 路径。

一项合成测试展示了这项改动在大规模网络命名空间管理中的潜力：并行创建 4,096 个网络命名空间，并为每个命名空间添加 1,024 条规则时：

• IPv4 用时从 22.752 秒降至 0.918 秒，约提升 24.8 倍；
• IPv6 用时从 35.181 秒降至 1.214 秒，约提升 29.0 倍。

这组数据反映的是极端锁竞争场景，并不意味着普通容器启动或所有路由工作负载都会获得同等幅度的加速。

AI 补丁太多，维护者开始寻找新的分流方式

Linux 网络子系统的另一项变化，来自开发流程本身。网络维护者 Jakub Kicinski 表示，当前统计中有 632 个 net 补丁和 648 个 net-next 补丁。他估计，net-next 中约有三分之一至二分之一是由 AI 驱动产生的低优先级修复、清理或说明性修改，折算下来约为 216 至 324 个补丁。Kicinski 和 Paolo Abeni 形容由此带来的工作量已经“完全不堪重负”。

提出的解决方案并不是让某一个模型取代维护者。Meta 提供了预算和多个前沿模型的使用权限，让补丁先接受多模型初步审查，以降低单个模型产生幻觉或误判后直接影响开发流程的风险。

计划中的自动化工作包括：

• 管理 Patchwork 中的补丁状态；
• 提供常规流程反馈；
• 修改提交信息；
• 在可信人员已经审查过的前提下，考虑自动应用部分补丁。

这些工作相对结构化，适合用来减少重复性劳动。但它们与判断一个补丁是否会在罕见故障路径中出错，是两类不同的问题。

内核网络代码涉及并发、API 契约和故障恢复顺序。维护者特别指出，罕见竞态以及 PCIe 错误、超时处理等硬件恢复路径，仍然需要人类仔细审查。AI 可以帮助过滤重复工作，却不能消除对同步规则和恢复逻辑的理解要求。

新驱动与协议改进

本次网络合并还包含多项硬件支持和协议改进：

• 初步加入 Morse Micro mm81x Wi-Fi HaLow 驱动，支持 USB 和 SDIO 设备；
• 新增 NXPWIFI 无线驱动，NXP 多链路操作相关工作仍在继续；
• Intel 获得初版 iXD 驱动框架，用于支持 E2100 及后续 IPU 和 FNIC 上的 Control Plane PIC Function；
• 有线网络加入 AMD/Solarflare 网卡的初步 CXL 支持，并支持为 AMD Pensando 硬件刷写固件。

此外，MPTCP 在极端内存压力下新增了最后手段：清理乱序队列。这是面向内存受限条件的恢复措施，并不代表日常传输吞吐量一定会提高。

AF_UNIX 的文件描述符传递也更容易排查问题。启用 SO_RIGHTS_NOTRUNC 后，如果 LSM 在 SCM_RIGHTS 数组中拒绝某个文件描述符，接收方可以识别具体被拒绝的描述符及其 errno，而不必在遇到第一个拒绝后丢失数组中的其余内容。

Linux 7.3 什么时候发布？

按照目前的开发节奏，Linux 7.3 的首个候选版本预计在 2026 年 8 月 30 日左右出现，稳定版预计在 10 月下旬发布，但具体时间仍取决于正常的发布周期。

这并不意味着大多数服务器和桌面系统会在 10 月立即获得这些网络功能。各 Linux 发行版会自行选择内核版本、回移部分改动、完成测试并安排发布。滚动更新发行版可能更早打包，而固定版本发行版通常需要明显更长时间。

CachyOS 由于采用滚动更新模式，理论上可能成为较早采用者之一。不过，现有的 8 月版本信息显示，其安装镜像仍使用 Linux 7.1，并未确认 Linux 7.3 的具体采用日期。

这次合并对用户意味着什么？

对基础设施团队而言，最值得关注的是 BIG TCP 对 VXLAN/Geneve 覆盖路径的支持，以及大规模并行管理网络命名空间时锁竞争的下降。两者尤其适合在高吞吐覆盖网络，或需要同时创建、配置大量命名空间的环境中进行验证。

对内核开发者而言，AI 审查试验可能同样重要。此次合并展现出一种更现实的分工：模型负责吸收重复性的补丁分流和流程反馈，维护者则继续把精力集中在那些表面上合理、却可能导致死锁、错误处理硬件恢复或破坏隐含同步规则的少见场景上。

因此，Linux 7.3 正带着一组相当可观的网络功能进入后续开发阶段。但在大多数用户能够依赖这些改动之前，它仍需要经过候选版本测试、硬件验证和各发行版的集成。