netkit 邁向 VM 封包零複製接收，BPF 使用者空間熱修仍是紙上談兵
LWN.net · 2026-07-24
在 2026 年 5 月於克羅埃西亞札格雷布舉行的 LSF/MM/BPF Summit 上，netkit 與 Cilium 的主要維護者 Daniel Borkmann 報告了 netkit 子系統的最新進展：封包現在已能零複製地送進網路命名空間內的虛擬機。議程時間尚有餘裕時，他進一步拋出一個更大膽的構想——用 BPF 對執行中的使用者空間程式做熱修補，但這部分目前完全停留在概念發想，尚無任何 patch 存在。
背景：netkit 的裝置模型
netkit 於 Linux 6.7 合併進主線，最初的 patch 系列標題為「netkit, bpf: Add bpf programmable net device」，作者同樣是 Daniel Borkmann。它與傳統 veth 的關鍵差異，在於把 BPF 程式直接掛在裝置的收發路徑（xmit path）上，略過一般網路裝置會經過的 qdisc 與 per-CPU backlog queue，藉此降低延遲、提高輸送量，特別適合 Cilium 這類需要在容器與命名空間之間頻繁轉送封包的場景。
核心改動：VM 封包零複製接收
本次談話報告的進展，是讓 netkit 支援把封包零複製地接收進網路命名空間裡的虛擬機——換句話說，封包從實體網卡收下之後，不需要在 host 端額外拷貝一份，就能直接讓 guest 端讀到。這對執行大量輕量 VM（例如 KubeVirt 之類把 VM 當 Pod 用的場景）特別有意義，因為每一次拷貝都會吃掉 CPU 週期並增加延遲，零複製路徑等於把 netkit 原本針對容器設計的效能優勢，延伸到 VM workload 上。
影響範圍：仍屬推想的使用者空間熱修
相較之下，Borkmann 提出的 BPF 使用者空間熱修構想則完全是另一回事：概念上類似核心的 live patching，讓 BPF 程式能在不重啟行程的前提下，攔截並替換使用者空間函式的行為。LWN 的報導明確指出這個想法「完全屬於推測性質」，目前沒有對應的 kernel patch 系列、也沒有 RFC 討論串可以追蹤，純粹是 Borkmann 在會議室裡拋出來試水溫的方向。
原始來源：LWN.net: An update on netkit and the use of BPF in user space、lore.kernel.org: netkit, bpf: Add bpf programmable net device
BPF 追蹤程式終於能一次掛上多個 tracepoint，預計進 Linux 7.2
LWN.net · 2026-07-22
Jiri Olsa 主導的 tracing_multi link patch 系列已合併進 bpf-next，讓單一 BPF 追蹤程式能同時掛載到多個 fentry／fexit／tracepoint 掛點，預計隨 Linux 7.2 一併釋出。這項工作先前曾在 2026 年的 LSF/MM/BPF Summit 上由 Olsa 親自報告進度，如今正式合併結束了長達數個版本的 review 過程。
背景：一個掛點只能掛一支程式的限制
在此之前，BPF_PROG_TYPE_TRACING 類型的程式只能綁定單一掛點，即使多個核心函式要套用完全相同的追蹤邏輯，開發者也得為每個函式各自載入一份程式。這種一對一的限制會白白消耗記憶體，也拖慢程式載入速度，尤其在需要同時追蹤數十甚至上百個函式時特別明顯，這正是 Olsa 系列想解決的核心痛點。
核心改動：trampoline 多連結架構
這次合併的 17-patch 系列（cover letter 標題「bpf: tracing_multi link」，2026 年 2 月由 jolsa@kernel.org 送出）引入了 struct bpf_tramp_multi_link 與對應的 bpf_trampoline_multi_link／bpf_trampoline_multi_unlink_prog 介面，並新增三種掛載型態：BPF_TRACE_FENTRY_MULTI、BPF_TRACE_FEXIT_MULTI、BPF_MODIFY_RETURN_MULTI。
- 重構
bpf_tramp_node結構，讓每個節點直接持有指向bpf_link的指標 - 新增 trampoline mutex pool，避免多連結情境下的鎖競爭
- 支援 session 與 cookie，讓單一掛載仍可攜帶每次呼叫的上下文資料
- libbpf 一併補上對應的多連結掛載 API
此設計延伸自先前已存在的 freplace 多連結掛載機制，把原本只給少數場景用的能力，擴大套用到一般的 tracing 程式類型上；作者在 cover letter 中也提到 linkinfo／fdinfo 支援與更完整的 rollback 測試會留待後續系列補齊。
影響範圍
對維運與可觀測性工具（例如追蹤數十個 syscall 或函式入口的效能分析器）而言，這代表可以用一支 BPF 程式涵蓋多個掛點，省下大量重複載入的開銷。目前的合併範圍涵蓋 x86_64、arm64 與 s390 的 selftests，顯示核心邏輯已跨架構驗證過，實際落地時間點則仍看 7.2 的發布排程。
原始來源：LWN.net: Attaching programs to multiple tracepoints、mail-archive: [PATCH bpf-next 00/17] bpf: tracing_multi link
意外發現：GCC libstdc++ 的 std::rotate 其實和單向版本是同一套演算法
isocpp.org 部落格 · 2026-07-23
Raymond Chen 在他的 The Old New Thing 系列文章中發現，GCC libstdc++ 針對 random-access iterator 實作的 std::rotate，本質上跟他先前介紹過的「單向（forward-iterator）旋轉演算法」是同一套邏輯，只是換了個角度描述。isocpp.org 於 2026 年 7 月 23 日轉載並摘要了這個發現，原始分析則分兩篇發表在 Chen 的個人部落格上。
背景：兩個看似不同的旋轉演算法
Chen 先前介紹過一種只需要 forward iterator 就能運作的旋轉演算法：把陣列切成 A、B 兩個區塊（A 較短），持續交換 first 與 mid 指標指向的元素並往前推進，直到 mid 走到 last；此時 B 區塊的元素已全部歸位，但 A 區塊的元素會被打散成兩段，需要遞迴地再旋轉一次才能歸位。這個演算法只需要單向走訪，總共執行 n − 1 次交換，且 first 幾乎全程往前移動，僅需 O(log(min(|A|,|B|))) 次回退，區域性（locality）相當好。
核心發現：GCC 版本其實是同一套邏輯
Chen 以範例陣列 [A1, A2, A3, B1, B2, B3, B4, B5] 逐步比對兩個演算法的執行過程，發現 GCC libstdc++ 針對 random-access iterator 的版本，同樣是不斷交換 first 與 mid，得到的中間結果與最終結果和單向演算法完全一致。兩者唯一的差別在於對稱性：GCC 的版本是雙向的，當較大的區塊落在右側時會改成從右往左交換；而單向演算法則堅持固定由左往右處理，不論哪一側區塊比較大。
影響範圍
這個發現本身不涉及效能改動或行為變更，libstdc++ 的 std::rotate 實作沒有任何程式碼異動；它的意義在於釐清了長久以來被視為「兩種不同演算法」的實作，其實可以用同一套遞迴/交換模型解釋。Chen 在文中把這種體驗形容為「發現兩件事其實是同一件事，只是標籤不同」的極客式樂趣，並預告下一篇會用 cycle decomposition 的角度分析 clang libc++ 的旋轉實作，屆時三大標準庫實作方式的關係會更清楚。
原始來源：isocpp.org: A shocking discovery about gcc's unidirectional rotation algorithm、The Old New Thing: 二次分析原文、The Old New Thing: 單向旋轉演算法原文