BIG TCP 可以穿過 VXLAN、Geneve

今次更新為 VXLAN 及 Geneve driver 加入 BIG TCP 支援，令大型 TCP super-segment 可以繼續以聚合狀態通過這些以 UDP 為基礎的 overlay tunnel。簡單講，系統可以在內部處理較少、但每個更大的封包，從而減低逐個封包處理所帶來的開銷。

這項改動並不等於要更改已設定的 link MTU。現有報道指出，即使是採用標準 MTU 的部署環境，或者網絡卡沒有硬件 tunnel offload 支援，軟件處理較少大型封包仍可能帶來好處。

支援 BIG TCP 的 patch series 亦處理了 tunnel 路徑中對封包長度的舊有假設：部分程式碼原本假設 skb->len 不會超過 64 KiB，或把長度存放在 16-bit 欄位，令更大型的封包被截短。相關工作涵蓋 VXLAN 及 Geneve 的 BIG TCP IPv4、IPv6 workload。

FIB 規則更新減少全局 RTNL 鎖競爭

另一項關鍵改動，是減少 FIB rule 操作對全局 RTNL lock 的依賴，包括 RTM_NEWRULE 及 RTM_DELRULE。

RTNL 是 Linux 網絡子系統內用來協調多項網絡設定操作的全局鎖。當系統需要同時在大量 network namespace 內修改路由規則時，過度依賴這個全局鎖會令操作被迫排隊。今次調整的目標，就是讓不同 namespace 的 FIB rule 工作有更多並行空間。

不過要留意，現有資料只確立了架構上的並行化方向，並沒有提供可靠而精確的 IPv4 或 IPv6 benchmark 加速數字。因此，暫時不能下結論說效能一定提升幾多個百分比或倍數。

其他 driver 及協議層更新

今次 networking pull 亦帶來多方面硬件及協議支援：

• 無線網絡部分加入 Morse Micro mm81x driver，針對長距離 S1G 裝置；同時加入新的 NXPWIFI driver。
• Intel iXD 基礎設施的初步支援，目標是 Intel E2100 及之後型號的 IPU 和 FNIC 上的 Intel Control Plane PIC Function。
• MPTCP 在極端記憶體壓力下改善處理方式，包括修剪 out-of-order receive queue。
• 整個 networking pull 亦包含其他有線、無線網絡修正，以及多項 driver 和子系統更新。

以上是 Linux 7.3 開發周期中進入 mainline 的網絡程式碼，並不代表 Linux 7.3 穩定正式版已經推出。

點解維護者會話「忙到透頂」？

Kicinski 及 Abeni 表示，今次 networking pull 合併了 632 個 net patch 及 648 個 net-next patch，合共 1,280 個。兩人亦特別提醒，單看這個數字仍未反映完整的 review 負擔。

他們作出的「快速而粗略」估算是：net-next patch 中約三分一至一半，似乎是由 AI 驅動、而且屬於低優先度的修正、清理或澄清工作。

提交量增加並非單一事件。另一個為期九日的時段內，網絡子系統收到 405 個標記為 [PATCH net] 的投稿，以及 687 個標記為 [PATCH net-next] 的投稿；當中 37% 被標記為 fixes。不過，由於部分投稿者未有一致使用正確標籤，這個 fixes 比例可能仍然偏低。

問題亦不只是 AI 能否寫出程式碼。AI 協助的投稿者可以低成本產生看似合理的解釋、bug report 及 review request；但每一項改動，仍然要由人手判斷是否有必要、是否正確和安全，以及是否值得合併。

維護者打算點樣用 AI 幫手？

維護者表示，他們已取得由 Meta 資助的多個大型語言模型使用權及預算，讓多個模型協助 review patch。短期目標，是在 patch 消耗更多人手 review 時間之前，先攔截部分幻覺內容或質素薄弱的改動。

他們亦計劃將模型導向較例行的工作，例如：

• 管理 Patchwork queue；
• 就常見的投稿流程問題提供回饋；
• 編輯 commit message；
• 在 patch 已經獲得可信任人士 review 標籤的情況下，考慮協助套用 patch。

這種做法是把 LLM 當成工作流程助手，而不是 subsystem maintainer 的替代品。對涉及並行處理的 Linux kernel 程式碼來說，兩者分別尤其重要。維護者指出，PCIe error 及 timeout 等罕見事件路徑，往往涉及難以重現的 timing-dependent race。LLM 可以協助找出可疑模式，但不能可靠地證明每一種罕見交錯執行都正確，亦不能保證沒有漏掉競態問題。

Linux 7.3 幾時有 rc1 及正式版？

現有來源沒有提供 Linux 7.3-rc1 或最終穩定版的確實預計日期。今次報道講的是在 7.3 開發周期、合併窗口內進入 mainline 的網絡變更，並不是已公布的正式版時間表。

同樣地，RTNL 改動雖然目標是改善跨多個 network namespace 的 FIB rule 並行操作，但目前資料不足以支持一個精確的 IPv4 或 IPv6 效能數字。現階段較穩妥的結論是：減少全局鎖競爭，應該會為高度並行的 namespace 管理工作提供更大擴展空間，但實際得益仍取決於工作負載及系統配置。

BIG TCP 可以穿過 VXLAN、Geneve

今次更新為 VXLAN 及 Geneve driver 加入 BIG TCP 支援，令大型 TCP super-segment 可以繼續以聚合狀態通過這些以 UDP 為基礎的 overlay tunnel。簡單講，系統可以在內部處理較少、但每個更大的封包，從而減低逐個封包處理所帶來的開銷。

這項改動並不等於要更改已設定的 link MTU。現有報道指出，即使是採用標準 MTU 的部署環境，或者網絡卡沒有硬件 tunnel offload 支援，軟件處理較少大型封包仍可能帶來好處。

支援 BIG TCP 的 patch series 亦處理了 tunnel 路徑中對封包長度的舊有假設：部分程式碼原本假設 skb->len 不會超過 64 KiB，或把長度存放在 16-bit 欄位，令更大型的封包被截短。相關工作涵蓋 VXLAN 及 Geneve 的 BIG TCP IPv4、IPv6 workload。

FIB 規則更新減少全局 RTNL 鎖競爭

另一項關鍵改動，是減少 FIB rule 操作對全局 RTNL lock 的依賴，包括 RTM_NEWRULE 及 RTM_DELRULE。

RTNL 是 Linux 網絡子系統內用來協調多項網絡設定操作的全局鎖。當系統需要同時在大量 network namespace 內修改路由規則時，過度依賴這個全局鎖會令操作被迫排隊。今次調整的目標，就是讓不同 namespace 的 FIB rule 工作有更多並行空間。

不過要留意，現有資料只確立了架構上的並行化方向，並沒有提供可靠而精確的 IPv4 或 IPv6 benchmark 加速數字。因此，暫時不能下結論說效能一定提升幾多個百分比或倍數。

其他 driver 及協議層更新

今次 networking pull 亦帶來多方面硬件及協議支援：

• 無線網絡部分加入 Morse Micro mm81x driver，針對長距離 S1G 裝置；同時加入新的 NXPWIFI driver。
• Intel iXD 基礎設施的初步支援，目標是 Intel E2100 及之後型號的 IPU 和 FNIC 上的 Intel Control Plane PIC Function。
• MPTCP 在極端記憶體壓力下改善處理方式，包括修剪 out-of-order receive queue。
• 整個 networking pull 亦包含其他有線、無線網絡修正，以及多項 driver 和子系統更新。

以上是 Linux 7.3 開發周期中進入 mainline 的網絡程式碼，並不代表 Linux 7.3 穩定正式版已經推出。

點解維護者會話「忙到透頂」？

Kicinski 及 Abeni 表示，今次 networking pull 合併了 632 個 net patch 及 648 個 net-next patch，合共 1,280 個。兩人亦特別提醒，單看這個數字仍未反映完整的 review 負擔。

他們作出的「快速而粗略」估算是：net-next patch 中約三分一至一半，似乎是由 AI 驅動、而且屬於低優先度的修正、清理或澄清工作。

提交量增加並非單一事件。另一個為期九日的時段內，網絡子系統收到 405 個標記為 [PATCH net] 的投稿，以及 687 個標記為 [PATCH net-next] 的投稿；當中 37% 被標記為 fixes。不過，由於部分投稿者未有一致使用正確標籤，這個 fixes 比例可能仍然偏低。

問題亦不只是 AI 能否寫出程式碼。AI 協助的投稿者可以低成本產生看似合理的解釋、bug report 及 review request；但每一項改動，仍然要由人手判斷是否有必要、是否正確和安全，以及是否值得合併。

維護者打算點樣用 AI 幫手？

維護者表示，他們已取得由 Meta 資助的多個大型語言模型使用權及預算，讓多個模型協助 review patch。短期目標，是在 patch 消耗更多人手 review 時間之前，先攔截部分幻覺內容或質素薄弱的改動。

他們亦計劃將模型導向較例行的工作，例如：

• 管理 Patchwork queue；
• 就常見的投稿流程問題提供回饋；
• 編輯 commit message；
• 在 patch 已經獲得可信任人士 review 標籤的情況下，考慮協助套用 patch。

這種做法是把 LLM 當成工作流程助手，而不是 subsystem maintainer 的替代品。對涉及並行處理的 Linux kernel 程式碼來說，兩者分別尤其重要。維護者指出，PCIe error 及 timeout 等罕見事件路徑，往往涉及難以重現的 timing-dependent race。LLM 可以協助找出可疑模式，但不能可靠地證明每一種罕見交錯執行都正確，亦不能保證沒有漏掉競態問題。

Linux 7.3 幾時有 rc1 及正式版？

現有來源沒有提供 Linux 7.3-rc1 或最終穩定版的確實預計日期。今次報道講的是在 7.3 開發周期、合併窗口內進入 mainline 的網絡變更，並不是已公布的正式版時間表。

同樣地，RTNL 改動雖然目標是改善跨多個 network namespace 的 FIB rule 並行操作，但目前資料不足以支持一個精確的 IPv4 或 IPv6 效能數字。現階段較穩妥的結論是：減少全局鎖競爭，應該會為高度並行的 namespace 管理工作提供更大擴展空間，但實際得益仍取決於工作負載及系統配置。