對於經常經過 overlay data path 的高吞吐量流量，這種做法有望減少逐個封包處理的成本。合併資料所列出的 netperf TCP_STREAM 測試結果如下：

• VXLAN 在標準 MTU 下由 34.44 Gbit/s 升至 39.56 Gbit/s，提升 14.9%。
• 在關閉 tunnel hardware offload 的情況下，VXLAN 由 21.82 Gbit/s 升至 29.39 Gbit/s，提升 34.7%。
• Geneve 在標準 MTU 下由 37.39 Gbit/s 升至 40.89 Gbit/s，提升 9.4%。

不過，呢幾個數字只反映特定測試配置，唔可以直接當成「所有 Linux 7.3 系統都會快幾多」。實際結果會受 gso_max_size、gro_max_size、NIC 能力、offload 設定、MTU、tunnel 類型及工作負載影響。運維團隊如要評估效能，仍然應該先對自己實際使用的 VXLAN 或 Geneve path 做 benchmark。

減少 RTNL 鎖競爭，namespace 大規模配置更快

另一項核心改動，是 IPv4 及 IPv6 FIB rule 的插入和刪除操作，減少依賴範圍廣泛的 RTNL lock。可行的情況下，相關工作會改用對應 fib_rules_ops 的 mutex 保護，讓更多操作可以並行進行。不過，RTNL 並非完全移除；部分流程仍然需要它，包括第一條 IPv4 rule 的 fib_unmerge() path。

測試以極端並行場景展示潛在收益：同時建立 4,096 個 network namespace，並在每個 namespace 加入 1,024 條 rule，IPv4 測試時間由 22.752 秒 降至 0.918 秒，約快 24.8 倍；IPv6 則由 35.181 秒 降至 1.214 秒，約快 29.0 倍。

要留意的是，這是用來量度嚴重 lock contention 的 synthetic test，並不等於一般 container 啟動，或者所有 routing workload 都會得到同樣幅度的改善。

AI patch 太多，維護者開始尋求模型幫手

Linux networking subsystem 今次亦成為 AI 輔助 kernel 開發的實驗場。Jakub Kicinski 表示，當時共有 632 個 net patch 及 648 個 net-next patch；他估計 net-next 當中約有三分一至一半屬於由 AI 推動的低優先度修正、清理或文字澄清工作，即大約 216 至 324 個 patch。Kicinski 與 Paolo Abeni 形容相關工作量令團隊「完全應付不來」。

提出的做法並非由一個 AI 模型取代 maintainer，而是由 Meta 提供預算及多個 frontier model 的使用權，讓每個 patch 可以先經多個模型作第一輪 review，降低單一模型出現 hallucination 或錯誤理解而無人察覺的風險。

計劃中的自動化工作包括：

• 管理 Patchwork；
• 提供日常流程回饋；
• 協助修改 commit message；
• 在可信任人士已經 review 後，考慮自動套用部分 patch。

這些工作相對有規律，比起判斷一項改動會否影響罕見故障路徑，較適合交由自動化工具先處理。

但在 kernel networking 入面，最關鍵的風險往往正正藏在不常見的情況。維護者特別指出，罕見 race condition，以及 PCIe error、timeout handling 等硬件 recovery path，仍然需要人手仔細檢查。AI 可以幫手篩走重複性工作，卻不能取代對 concurrency、API contract 及 recovery sequencing 的理解。

新 driver 及協議改進

今次 networking pull request 亦包括多項硬件支援及協議更新：

• Morse Micro mm81x Wi-Fi HaLow driver 首次加入，支援 USB 及 SDIO 裝置。
• 新增 NXP 的 NXPWIFI wireless driver，multi-link operation 相關工作亦繼續進行。
• Intel 加入 iXD driver 的初始骨架，用於 E2100 及後續 IPU、FNIC 的 Control Plane PIC Function 支援。
• 有線網絡方面，AMD/Solarflare NIC 獲得初始 CXL 支援；AMD Pensando 硬件則加入 firmware flashing 支援。

其他較細微但實用的改動包括：

• MPTCP 在極端記憶體壓力下，新增最後手段式的 out-of-order queue pruning。這主要是 recovery 機制，並不是承諾日常吞吐量會提升。
• AF_UNIX file-descriptor passing 變得較容易診斷。配合 SO_RIGHTS_NOTRUNC，如果 LSM 因安全政策拒絕 SCM_RIGHTS array 中某一個 file descriptor，receiver 可以知道被拒絕的是哪個 descriptor 及其 errno，而不是在第一個拒絕出現時連餘下 array 都一併失去。

Linux 7.3 幾時先會用到？

按目前預測，Linux 7.3 首個 release candidate 約於 2026 年 8 月 30 日 出現，穩定版則預計在 10 月下旬 推出，前提是開發週期按正常進度完成。

但 stable release 出街，並不代表大部分 server 或 desktop 即時就會用到這些網絡功能。各個 Linux distribution 會自行選擇 kernel 版本、backport 部分改動、進行測試，再按自己的時間表推出更新。rolling release 發行版可能較早包裝新 kernel；fixed-release 發行版則可能要等更耐。

CachyOS 因為採用 rolling 模式，理論上有機會較早跟進。不過，現有的 2026 年 8 月版本資料顯示，其安裝映像仍然使用 Linux 7.1，暫時未有證據確認它會在何時採用 Linux 7.3。

對實際部署有咩意義？

對 infrastructure 團隊來講，最值得立即觀察的，是 BIG TCP 對 VXLAN、Geneve overlay path 的影響，以及大規模建立及配置 network namespace 時，RTNL contention 減少後的表現。特別是同時具備高吞吐量 overlay 流量和大量 namespace 管理工作的環境，最值得自行測試。

對 kernel developer 來講，AI review 實驗可能同樣重要。今次合併反映出一種較務實的分工：由模型處理重複性 triage 及流程回饋，maintainer 則繼續負責少見但高風險的情況——例如可能造成 deadlock、錯誤處理硬件 recovery，或者違反隱含 synchronization rule 的改動。

所以，Linux 7.3 的 networking feature set 確實相當豐富，但在大部分使用者可以放心依賴之前，仍要經過 release-candidate 測試、硬件驗證，以及各個 distribution 的整合。

對於經常經過 overlay data path 的高吞吐量流量，這種做法有望減少逐個封包處理的成本。合併資料所列出的 netperf TCP_STREAM 測試結果如下：

• VXLAN 在標準 MTU 下由 34.44 Gbit/s 升至 39.56 Gbit/s，提升 14.9%。
• 在關閉 tunnel hardware offload 的情況下，VXLAN 由 21.82 Gbit/s 升至 29.39 Gbit/s，提升 34.7%。
• Geneve 在標準 MTU 下由 37.39 Gbit/s 升至 40.89 Gbit/s，提升 9.4%。

不過，呢幾個數字只反映特定測試配置，唔可以直接當成「所有 Linux 7.3 系統都會快幾多」。實際結果會受 gso_max_size、gro_max_size、NIC 能力、offload 設定、MTU、tunnel 類型及工作負載影響。運維團隊如要評估效能，仍然應該先對自己實際使用的 VXLAN 或 Geneve path 做 benchmark。

減少 RTNL 鎖競爭，namespace 大規模配置更快

另一項核心改動，是 IPv4 及 IPv6 FIB rule 的插入和刪除操作，減少依賴範圍廣泛的 RTNL lock。可行的情況下，相關工作會改用對應 fib_rules_ops 的 mutex 保護，讓更多操作可以並行進行。不過，RTNL 並非完全移除；部分流程仍然需要它，包括第一條 IPv4 rule 的 fib_unmerge() path。

測試以極端並行場景展示潛在收益：同時建立 4,096 個 network namespace，並在每個 namespace 加入 1,024 條 rule，IPv4 測試時間由 22.752 秒 降至 0.918 秒，約快 24.8 倍；IPv6 則由 35.181 秒 降至 1.214 秒，約快 29.0 倍。

要留意的是，這是用來量度嚴重 lock contention 的 synthetic test，並不等於一般 container 啟動，或者所有 routing workload 都會得到同樣幅度的改善。

AI patch 太多，維護者開始尋求模型幫手

Linux networking subsystem 今次亦成為 AI 輔助 kernel 開發的實驗場。Jakub Kicinski 表示，當時共有 632 個 net patch 及 648 個 net-next patch；他估計 net-next 當中約有三分一至一半屬於由 AI 推動的低優先度修正、清理或文字澄清工作，即大約 216 至 324 個 patch。Kicinski 與 Paolo Abeni 形容相關工作量令團隊「完全應付不來」。

提出的做法並非由一個 AI 模型取代 maintainer，而是由 Meta 提供預算及多個 frontier model 的使用權，讓每個 patch 可以先經多個模型作第一輪 review，降低單一模型出現 hallucination 或錯誤理解而無人察覺的風險。

計劃中的自動化工作包括：

• 管理 Patchwork；
• 提供日常流程回饋；
• 協助修改 commit message；
• 在可信任人士已經 review 後，考慮自動套用部分 patch。

這些工作相對有規律，比起判斷一項改動會否影響罕見故障路徑，較適合交由自動化工具先處理。

但在 kernel networking 入面，最關鍵的風險往往正正藏在不常見的情況。維護者特別指出，罕見 race condition，以及 PCIe error、timeout handling 等硬件 recovery path，仍然需要人手仔細檢查。AI 可以幫手篩走重複性工作，卻不能取代對 concurrency、API contract 及 recovery sequencing 的理解。

新 driver 及協議改進

今次 networking pull request 亦包括多項硬件支援及協議更新：

• Morse Micro mm81x Wi-Fi HaLow driver 首次加入，支援 USB 及 SDIO 裝置。
• 新增 NXP 的 NXPWIFI wireless driver，multi-link operation 相關工作亦繼續進行。
• Intel 加入 iXD driver 的初始骨架，用於 E2100 及後續 IPU、FNIC 的 Control Plane PIC Function 支援。
• 有線網絡方面，AMD/Solarflare NIC 獲得初始 CXL 支援；AMD Pensando 硬件則加入 firmware flashing 支援。

其他較細微但實用的改動包括：

• MPTCP 在極端記憶體壓力下，新增最後手段式的 out-of-order queue pruning。這主要是 recovery 機制，並不是承諾日常吞吐量會提升。
• AF_UNIX file-descriptor passing 變得較容易診斷。配合 SO_RIGHTS_NOTRUNC，如果 LSM 因安全政策拒絕 SCM_RIGHTS array 中某一個 file descriptor，receiver 可以知道被拒絕的是哪個 descriptor 及其 errno，而不是在第一個拒絕出現時連餘下 array 都一併失去。

Linux 7.3 幾時先會用到？

按目前預測，Linux 7.3 首個 release candidate 約於 2026 年 8 月 30 日 出現，穩定版則預計在 10 月下旬 推出，前提是開發週期按正常進度完成。

但 stable release 出街，並不代表大部分 server 或 desktop 即時就會用到這些網絡功能。各個 Linux distribution 會自行選擇 kernel 版本、backport 部分改動、進行測試，再按自己的時間表推出更新。rolling release 發行版可能較早包裝新 kernel；fixed-release 發行版則可能要等更耐。

CachyOS 因為採用 rolling 模式，理論上有機會較早跟進。不過，現有的 2026 年 8 月版本資料顯示，其安裝映像仍然使用 Linux 7.1，暫時未有證據確認它會在何時採用 Linux 7.3。

對實際部署有咩意義？

對 infrastructure 團隊來講，最值得立即觀察的，是 BIG TCP 對 VXLAN、Geneve overlay path 的影響，以及大規模建立及配置 network namespace 時，RTNL contention 減少後的表現。特別是同時具備高吞吐量 overlay 流量和大量 namespace 管理工作的環境，最值得自行測試。

對 kernel developer 來講，AI review 實驗可能同樣重要。今次合併反映出一種較務實的分工：由模型處理重複性 triage 及流程回饋，maintainer 則繼續負責少見但高風險的情況——例如可能造成 deadlock、錯誤處理硬件 recovery，或者違反隱含 synchronization rule 的改動。

所以，Linux 7.3 的 networking feature set 確實相當豐富，但在大部分使用者可以放心依賴之前，仍要經過 release-candidate 測試、硬件驗證，以及各個 distribution 的整合。