目前公布的 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 綁定的 mutex，讓更多操作不必全部排隊等待同一把全域鎖。不過部分情境仍需要 RTNL，例如第一條 IPv4 規則的 fib_unmerge() 路徑。

一項針對高並行 Network Namespace 管理的合成測試，凸顯了這項調整的潛力：平行建立 4,096 個網路命名空間，並在每個命名空間加入 1,024 條規則後，IPv4 測試時間由 22.752 秒 降至 0.918 秒，約快 24.8 倍；IPv6 則由 35.181 秒 降至 1.214 秒，約快 29.0 倍。

這是針對極端鎖競爭情境的測量，並不代表一般容器啟動流程或所有路由工作負載都會獲得同等幅度的改善。

AI 補丁增加，維護者開始尋求自動化分流

Linux 網路子系統也成為 AI 輔助核心開發的實驗場。網路維護者 Jakub Kicinski 表示，目前有 632 個 net 補丁與 648 個 net-next 補丁；他估計 net-next 中約有三分之一至一半屬於由 AI 驅動的低優先級修正、清理或文字澄清工作，換算約 216 至 324 個補丁。Kicinski 與 Paolo Abeni 形容相關工作量已讓團隊「完全不堪負荷」。

目前提出的解法並不是由單一 AI 模型取代維護者。Meta 提供預算與多個前沿模型的使用權，讓每份補丁可以先接受多模型的初步審查，降低單一模型產生幻覺或誤判後直接影響流程的風險。

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

• 管理 Patchwork 補丁流程；
• 提供例行流程回饋；
• 編修 commit message；
• 在可信任人員已完成審查後，視情況套用補丁。

這些任務的結構較明確，比起判斷罕見失效路徑是否正確，更適合交由自動化工具處理。

但在核心網路程式碼中，真正棘手的往往正是罕見情況。維護者指出，競態條件與硬體復原路徑——例如 PCIe 錯誤與逾時處理——仍需要人類仔細檢查。AI 可以協助篩掉重複性工作，卻不能取代對並行處理、API 契約與復原順序的理解。

新驅動程式與協定改進

此次網路合併也帶來多項硬體支援與協定更新：

• Morse Micro mm81x Wi-Fi HaLow 驅動程式首次加入，支援 USB 與 SDIO 裝置。
• 新增 NXP 的 NXPWIFI 無線驅動程式，多鏈路運作（MLO）相關工作仍在持續。
• 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 對 Overlay 網路路徑的支援，以及大規模網路命名空間規則管理時降低鎖競爭的效果。若環境同時使用 VXLAN 或 Geneve、高吞吐量流量，並且會平行建立與設定大量 Network Namespace，這些改動尤其值得進行實機驗證。

對核心開發者來說，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 綁定的 mutex，讓更多操作不必全部排隊等待同一把全域鎖。不過部分情境仍需要 RTNL，例如第一條 IPv4 規則的 fib_unmerge() 路徑。

一項針對高並行 Network Namespace 管理的合成測試，凸顯了這項調整的潛力：平行建立 4,096 個網路命名空間，並在每個命名空間加入 1,024 條規則後，IPv4 測試時間由 22.752 秒 降至 0.918 秒，約快 24.8 倍；IPv6 則由 35.181 秒 降至 1.214 秒，約快 29.0 倍。

這是針對極端鎖競爭情境的測量，並不代表一般容器啟動流程或所有路由工作負載都會獲得同等幅度的改善。

AI 補丁增加，維護者開始尋求自動化分流

Linux 網路子系統也成為 AI 輔助核心開發的實驗場。網路維護者 Jakub Kicinski 表示，目前有 632 個 net 補丁與 648 個 net-next 補丁；他估計 net-next 中約有三分之一至一半屬於由 AI 驅動的低優先級修正、清理或文字澄清工作，換算約 216 至 324 個補丁。Kicinski 與 Paolo Abeni 形容相關工作量已讓團隊「完全不堪負荷」。

目前提出的解法並不是由單一 AI 模型取代維護者。Meta 提供預算與多個前沿模型的使用權，讓每份補丁可以先接受多模型的初步審查，降低單一模型產生幻覺或誤判後直接影響流程的風險。

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

• 管理 Patchwork 補丁流程；
• 提供例行流程回饋；
• 編修 commit message；
• 在可信任人員已完成審查後，視情況套用補丁。

這些任務的結構較明確，比起判斷罕見失效路徑是否正確，更適合交由自動化工具處理。

但在核心網路程式碼中，真正棘手的往往正是罕見情況。維護者指出，競態條件與硬體復原路徑——例如 PCIe 錯誤與逾時處理——仍需要人類仔細檢查。AI 可以協助篩掉重複性工作，卻不能取代對並行處理、API 契約與復原順序的理解。

新驅動程式與協定改進

此次網路合併也帶來多項硬體支援與協定更新：

• Morse Micro mm81x Wi-Fi HaLow 驅動程式首次加入，支援 USB 與 SDIO 裝置。
• 新增 NXP 的 NXPWIFI 無線驅動程式，多鏈路運作（MLO）相關工作仍在持續。
• 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 對 Overlay 網路路徑的支援，以及大規模網路命名空間規則管理時降低鎖競爭的效果。若環境同時使用 VXLAN 或 Geneve、高吞吐量流量，並且會平行建立與設定大量 Network Namespace，這些改動尤其值得進行實機驗證。

對核心開發者來說，AI 補丁審查實驗的長期影響可能同樣重要。這次合併顯示出一種務實的分工：模型負責吸收重複性的分類與流程回饋，維護者則繼續掌握那些表面上合理、卻可能造成死結、錯誤處理硬體復原，或違反隱含同步規則的少見案例。

Linux 7.3 的網路功能集已大致成形，但在正式發布前，仍需要經過候選版本測試、硬體驗證，以及各發行版的整合流程。對多數使用者而言，真正能穩定用上這些變更，還需要再等一段時間。