支援 BIG TCP 的 patch series 亦處理了 tunnel 路徑中對封包長度的舊有假設:部分程式碼原本假設 skb->len 不會超過 64 KiB,或把長度存放在 16-bit 欄位,令更大型的封包被截短。相關工作涵蓋 VXLAN 及 Geneve 的 BIG TCP IPv4、IPv6 workload。
RTNL 是 Linux 網絡子系統內用來協調多項網絡設定操作的全局鎖。當系統需要同時在大量 network namespace 內修改路由規則時,過度依賴這個全局鎖會令操作被迫排隊。今次調整的目標,就是讓不同 namespace 的 FIB rule 工作有更多並行空間。
不過要留意,現有資料只確立了架構上的並行化方向,並沒有提供可靠而精確的 IPv4 或 IPv6 benchmark 加速數字。因此,暫時不能下結論說效能一定提升幾多個百分比或倍數。
今次 networking pull 亦帶來多方面硬件及協議支援:
Kicinski 及 Abeni 表示,今次 networking pull 合併了 632 個 net patch 及 648 個 net-next patch,合共 1,280 個。兩人亦特別提醒,單看這個數字仍未反映完整的 review 負擔。
提交量增加並非單一事件。另一個為期九日的時段內,網絡子系統收到 405 個標記為 [PATCH net][PATCH net-next]
問題亦不只是 AI 能否寫出程式碼。AI 協助的投稿者可以低成本產生看似合理的解釋、bug report 及 review request;但每一項改動,仍然要由人手判斷是否有必要、是否正確和安全,以及是否值得合併。
維護者表示,他們已取得由 Meta 資助的多個大型語言模型使用權及預算,讓多個模型協助 review patch。短期目標,是在 patch 消耗更多人手 review 時間之前,先攔截部分幻覺內容或質素薄弱的改動。
他們亦計劃將模型導向較例行的工作,例如:
這種做法是把 LLM 當成工作流程助手,而不是 subsystem maintainer 的替代品。對涉及並行處理的 Linux kernel 程式碼來說,兩者分別尤其重要。維護者指出,PCIe error 及 timeout 等罕見事件路徑,往往涉及難以重現的 timing-dependent race。LLM 可以協助找出可疑模式,但不能可靠地證明每一種罕見交錯執行都正確,亦不能保證沒有漏掉競態問題。
同樣地,RTNL 改動雖然目標是改善跨多個 network namespace 的 FIB rule 並行操作,但目前資料不足以支持一個精確的 IPv4 或 IPv6 效能數字。現階段較穩妥的結論是:減少全局鎖競爭,應該會為高度並行的 namespace 管理工作提供更大擴展空間,但實際得益仍取決於工作負載及系統配置。