需要注意的是，这些代码是在 Linux 7.3 的开发合并窗口期间进入主线，并不代表 Linux 7.3 稳定版已经发布。

BIG TCP 进入 VXLAN 和 Geneve 隧道

此次合并为 VXLAN 和 Geneve 驱动加入 BIG TCP 支持。简单来说，BIG TCP 允许系统将多个 TCP 数据包聚合成更大的“超级报文”，再进行处理。现在，这种较大的报文可以继续穿过基于 UDP 的覆盖隧道，有望减少每个数据包都要重复执行的处理工作。

它的意义并不只限于超大 MTU 网络。现有报道指出，即使部署使用标准 MTU，或者网卡不支持隧道硬件卸载，系统仍可能通过在软件内部处理更少、更大的报文而获益。这里的重点是降低每包处理开销，而不是改变管理员配置的链路 MTU。

为让 BIG TCP 适用于 VXLAN 和 Geneve，相关补丁还修正了隧道路经中对报文长度的假设：部分代码此前默认 skb->len 小于 64 KiB，或将长度存放在 16 位字段中，可能导致大报文长度被截断。补丁系列同时覆盖 BIG TCP 的 IPv4 和 IPv6 工作负载。

FIB 路由规则操作减少全局 RTNL 锁竞争

另一项关键变化针对 FIB 规则操作，例如 RTM_NEWRULE 和 RTM_DELRULE。相关改动减少了这些操作对全局 RTNL 锁的依赖。

RTNL 是 Linux 网络子系统中的全局锁之一。此前，当系统同时管理多个网络命名空间中的路由规则时，部分操作可能被同一个全局串行化点限制。新设计的目标，是让不同网络命名空间中的 FIB 规则操作拥有更大的并行空间。

现有资料支持“减少全局锁竞争、改善并行性”这一架构层面的判断，但没有提供可靠且精确的 IPv4 或 IPv6 基准测试增幅。因此，暂时无法据此给出具体的百分比或性能倍数；实际收益仍取决于工作负载、网络命名空间数量和系统配置。

无线、网卡与协议栈也有更新

这次网络子系统合并还包含多项驱动和协议层改动：

• 无线部分加入 Morse Micro mm81x 驱动，面向远距离 S1G 设备；同时加入新的 NXPWIFI 驱动。
• Intel iXD 基础设施获得初步支持，目标是 Intel E2100 及后续平台上的 Control Plane PIC Function，以及相关 IPU 和 FNIC 场景。
• MPTCP 在极端内存压力下的处理得到改进，包括清理乱序接收队列，以降低内存紧张时的压力。
• 更广泛的网络合并还包括有线、无线、协议栈和驱动层面的其他修复与改进。

为什么维护者会说“完全不堪重负”

Kicinski 和 Abeni 在网络合并说明中给出的“快速且粗略”的统计显示，他们合并了 632 个 net 补丁和 648 个 net-next 补丁，合计 1,280 个。

但真正的审查负担并不止于这个数字。维护者估计，net-next 补丁中约三分之一至一半看起来是由 AI 驱动生成的低优先级修复、代码清理或说明性修改。

此前的投稿量也显示出类似趋势：在一个 9 天的时间窗口内，网络子系统收到 405 个标记为 [PATCH net] 的投稿，以及 687 个标记为 [PATCH net-next] 的投稿。其中 37% 被标记为修复补丁，但由于投稿者可能没有正确使用标签，这一比例还可能被低估。

问题并不只是 AI 能否写出代码。借助大语言模型，生成看似合理的解释、错误报告和审查请求同样变得非常廉价。最终，仍需要人类维护者逐一判断：补丁是否真的有必要、实现是否正确、是否存在安全风险，以及它是否值得进入内核主线。

维护者准备如何使用 AI

维护者表示，他们已经获得 Meta 提供的资金支持和访问权限，可以使用多个大语言模型对补丁进行审查。眼下的目标，是在补丁占用更多人工审查时间之前，尽可能发现其中的幻觉内容或薄弱改动。

他们计划让大语言模型更多承担流程性工作，包括：

• 管理 Patchwork 补丁队列；
• 对常见的投稿流程问题提供反馈；
• 编辑提交说明；
• 在可信维护者或审阅者已经打上审查标签后，视情况自动应用补丁。

这说明维护者更倾向于把 LLM 当作工作流助手，而不是子系统维护者的替代品。对于涉及并发和时序的内核代码，这一区别尤其重要。

维护者特别提到了 PCIe 错误和超时等罕见事件路径。此类场景中的竞争条件往往只在非常特殊的时序交错下出现，难以稳定复现，也很难证明不存在。LLM 可以帮助指出可疑模式，却不能可靠地为每一种罕见并发交错证明代码正确。

Linux 7.3 何时发布？目前仍没有可靠时间表

现有资料没有给出 Linux 7.3 首个候选版本（rc1）或最终稳定版的确定日期。此次报道描述的是已经进入 Linux 7.3 开发周期的网络代码，而不是一份正式的发布日程。

因此，目前最稳妥的结论是：Linux 7.3 网络子系统在功能上继续扩展，尤其加强了覆盖网络和高并行路由管理能力；但与此同时，AI 生成补丁和相关审查请求的快速增加，正在把 Linux 内核长期依赖的人工维护流程推向新的压力测试。

需要注意的是，这些代码是在 Linux 7.3 的开发合并窗口期间进入主线，并不代表 Linux 7.3 稳定版已经发布。

BIG TCP 进入 VXLAN 和 Geneve 隧道

此次合并为 VXLAN 和 Geneve 驱动加入 BIG TCP 支持。简单来说，BIG TCP 允许系统将多个 TCP 数据包聚合成更大的“超级报文”，再进行处理。现在，这种较大的报文可以继续穿过基于 UDP 的覆盖隧道，有望减少每个数据包都要重复执行的处理工作。

它的意义并不只限于超大 MTU 网络。现有报道指出，即使部署使用标准 MTU，或者网卡不支持隧道硬件卸载，系统仍可能通过在软件内部处理更少、更大的报文而获益。这里的重点是降低每包处理开销，而不是改变管理员配置的链路 MTU。

为让 BIG TCP 适用于 VXLAN 和 Geneve，相关补丁还修正了隧道路经中对报文长度的假设：部分代码此前默认 skb->len 小于 64 KiB，或将长度存放在 16 位字段中，可能导致大报文长度被截断。补丁系列同时覆盖 BIG TCP 的 IPv4 和 IPv6 工作负载。

FIB 路由规则操作减少全局 RTNL 锁竞争

另一项关键变化针对 FIB 规则操作，例如 RTM_NEWRULE 和 RTM_DELRULE。相关改动减少了这些操作对全局 RTNL 锁的依赖。

RTNL 是 Linux 网络子系统中的全局锁之一。此前，当系统同时管理多个网络命名空间中的路由规则时，部分操作可能被同一个全局串行化点限制。新设计的目标，是让不同网络命名空间中的 FIB 规则操作拥有更大的并行空间。

现有资料支持“减少全局锁竞争、改善并行性”这一架构层面的判断，但没有提供可靠且精确的 IPv4 或 IPv6 基准测试增幅。因此，暂时无法据此给出具体的百分比或性能倍数；实际收益仍取决于工作负载、网络命名空间数量和系统配置。

无线、网卡与协议栈也有更新

这次网络子系统合并还包含多项驱动和协议层改动：

• 无线部分加入 Morse Micro mm81x 驱动，面向远距离 S1G 设备；同时加入新的 NXPWIFI 驱动。
• Intel iXD 基础设施获得初步支持，目标是 Intel E2100 及后续平台上的 Control Plane PIC Function，以及相关 IPU 和 FNIC 场景。
• MPTCP 在极端内存压力下的处理得到改进，包括清理乱序接收队列，以降低内存紧张时的压力。
• 更广泛的网络合并还包括有线、无线、协议栈和驱动层面的其他修复与改进。

为什么维护者会说“完全不堪重负”

Kicinski 和 Abeni 在网络合并说明中给出的“快速且粗略”的统计显示，他们合并了 632 个 net 补丁和 648 个 net-next 补丁，合计 1,280 个。

但真正的审查负担并不止于这个数字。维护者估计，net-next 补丁中约三分之一至一半看起来是由 AI 驱动生成的低优先级修复、代码清理或说明性修改。

此前的投稿量也显示出类似趋势：在一个 9 天的时间窗口内，网络子系统收到 405 个标记为 [PATCH net] 的投稿，以及 687 个标记为 [PATCH net-next] 的投稿。其中 37% 被标记为修复补丁，但由于投稿者可能没有正确使用标签，这一比例还可能被低估。

问题并不只是 AI 能否写出代码。借助大语言模型，生成看似合理的解释、错误报告和审查请求同样变得非常廉价。最终，仍需要人类维护者逐一判断：补丁是否真的有必要、实现是否正确、是否存在安全风险，以及它是否值得进入内核主线。

维护者准备如何使用 AI

维护者表示，他们已经获得 Meta 提供的资金支持和访问权限，可以使用多个大语言模型对补丁进行审查。眼下的目标，是在补丁占用更多人工审查时间之前，尽可能发现其中的幻觉内容或薄弱改动。

他们计划让大语言模型更多承担流程性工作，包括：

• 管理 Patchwork 补丁队列；
• 对常见的投稿流程问题提供反馈；
• 编辑提交说明；
• 在可信维护者或审阅者已经打上审查标签后，视情况自动应用补丁。

这说明维护者更倾向于把 LLM 当作工作流助手，而不是子系统维护者的替代品。对于涉及并发和时序的内核代码，这一区别尤其重要。

维护者特别提到了 PCIe 错误和超时等罕见事件路径。此类场景中的竞争条件往往只在非常特殊的时序交错下出现，难以稳定复现，也很难证明不存在。LLM 可以帮助指出可疑模式，却不能可靠地为每一种罕见并发交错证明代码正确。

Linux 7.3 何时发布？目前仍没有可靠时间表

现有资料没有给出 Linux 7.3 首个候选版本（rc1）或最终稳定版的确定日期。此次报道描述的是已经进入 Linux 7.3 开发周期的网络代码，而不是一份正式的发布日程。

因此，目前最稳妥的结论是：Linux 7.3 网络子系统在功能上继续扩展，尤其加强了覆盖网络和高并行路由管理能力；但与此同时，AI 生成补丁和相关审查请求的快速增加，正在把 Linux 内核长期依赖的人工维护流程推向新的压力测试。