Linuxネットワークスタック進化の軌跡: 過去10年の歩みと最新トレンド

ONIC2026 BOF

Transcript

1. ONIC 2026 BOF Linuxネットワークスタック進化の軌跡 - 過去 5 年の歩みと最新トレンド 10 v4.0 → v7.3: “skb or bypass” ではなく、用途ごとの共存の基盤へ 2026-11-12 Manabu Ori 1
2. 自己紹介 • • • 名前: 織学 (@orimanabu) 所属: Red Hat 仕事: RHELとOpenShiftの製品サポート
3. いきなりまとめ “skb or bypass” ではなく、用途ごとの共存の基盤へ v4.0 (2015-04) skb 中心の固定機能スタックに、パケット フィルタとしての BPF が付いたもの (速さが必要なら DPDK) 3 v7.3 用途ごとの複数の処理が共存でき、それらをス ケーラブルに制御する仕組みを持つ基盤 ① 拡張性の向上 ② 資源と制御の共通化 スタックの内側に差し込み点を増や し、BPF で検証&拡張 メモリ・queue・設定・o11yを、ドライ バ個別から共通基盤へ ③ 処理場所の選択 ④ 取捨選択 機能ごとに最適な場所(Kernel, Userland, NIC)で実行する 状況に応じて削除される機能も
4. 導入 本セッションの構成: 4つのテーマと2つの視点 テーマ 代表的な機能 拡張性の向上 プログラム可能なカーネル / パケットの 処理場所の拡張 BPF, struct_ops, kfunc, XDP, AF_XDP, TCX 資源と制御の共通化 メモリと queue の管理 / 大規模リソース 制御のスケーラビリティ page_pool, netmem, devmem TCP, netdev-genl, RTNL 処理場所の選択 トランスポートと暗号 / RDMA と netdev BBR, MPTCP, kTLS, PSP, QUIC, dma-buf 取捨選択 捨てたもの、まだ確定していないもの DCCP, DECnet, bpfilter, AppleTalk 視点① 選べる処理経路は、どう増えたか 4 視点② 誰が検証・所有・設定・観測するか
5. 序章 前提: v4.0 の時点でできたこと 分野 v4.0 までに入っていたもの キューの制御 BQL (v3.3)、CoDel (v3.5)、TSQ (v3.6)、fq (v3.12)、HHF・PIE (v3.14) BPF cls_bpf (v3.13)、bpf(2) システムコールとマップ (v3.18〜) フィルタ nftables (v3.13)、SYNPROXY (v3.12) 仮想化・トンネル OVS (v3.3)、VXLAN (v3.7)、Geneve・FOU (v3.18)、ipvlan (v3.19) TCP PRR、TFO、TLP・F-RTO、auto corking、DCTCP (v3.18) ソケット SO_REUSEPORT (v3.9)、busy poll (v3.11) スイッチ・ RDMA switchdev (v3.19)、ODP (v3.19) v4.0 の eBPF プログラム型は ソケットフィルタ 1 つだけ 5
6. 序章 進化の要因 6 CPU がボトルネックに クラウドとコンテナ 設定、観測が複雑に sk_buff のオーバーヘッドで 10G のwire speedに届かない (XDP の出発点) cloud native 環境での tc BPF の利用者の増加 (TCX の commit message) ethtool・sysfs・tc・devlink・netfi lter・ip・bridge に散在 (NetDev 0x17) AI の大規模通信 信頼と安全の要求 GPU あたり 400 Gbps の少数の大フロー。100 Gbps 以上では全サイクルが重要 パケットがカーネルを離れると、セキュリティ上の判断 ができない (2016 年の議論) いずれも講演発表者・commit authorの言葉
7. Linuxネットワークスタック10年の歴史 (抜粋) 取捨選 択 処理場所の選択 資源と制御の共通化 拡張性の向上 v4.0 2015-04 7 cgroup BPF XDP AF_XDP clsact → TCX netkit BTF struct_ops → BPF qdisc kfunc kptr / dynptr / arena CAP_BPF → token → 署名 MSG_ZEROCOPY → mmap io_uring ゼロコピー送信 page_pool → provider devmem TCP io_uring zcrx NAPI の制御 netdev-genl → queue lease extack → ethtool nl → YAML devlink RTNL 分割 (進行中 ) tc / nftables オフロード RACK-TLP BBR TCP ペーシング → EDT DualPI2 / AccECN / ECMP MPTCP (2009 頃から OOT) WireGuard / ovpn kTLS TCP-AO PSP クラウド RDMA 各種 RDMA dma-buf 対応 カーネル内 QUIC UET ドライバ (RFC) rxe/erdma dma-buf bpfilter DECnet DCCP RFC 6675 損失回復コード '15 主 commit 日〜最後の関連リリース v5.0 2019-03 '16 '17 '18 含まれる最初のリリース '19 v6.0 2022-10 '20 後続の拡張 '21 '22 '23 提案・未マージ v7.0 2026-04 '24 '25 削除 リリース日は版履歴による (v7.2・v7.3 は推定)。棒の左端は主 commit 日で、開発開始日ではない。 MPTCP の左端と提案の開始位置は目安。 '26 v4.10 v4.8 / 4.12 / 4.15 / 5.14 v4.18 / 5.4 / 5.8 / 6.6 v4.5 / 6.6 v6.7 / 7.1 v4.18 v5.6 / 6.16 v5.16 v5.19 / 6.9 v5.8 / 6.8 / 7.3 v4.14 / 4.18 v6.0 / 6.1 v4.18 / 5.14 / 6.11 / 6.15 v6.12 / 6.16 v6.15 v5.8 / 5.11 / 5.12 / 6.13 v6.3 / 6.8 / 6.9 / 7.1 v4.12 / 5.2 / 5.6 / 6.3 v4.6 / 5.1 / 5.12 / 5.14 / 6.2 v4.14 / 6.13 / 6.15 / 7.3 v4.6 / 5.1 / 5.3 / 5.5 / 6.3 v4.4 / 4.18 / 6.17 v4.9 v4.13 / 4.20 v6.17 / 6.18 / 7.2 v5.6 / 5.7 / 5.19 / 6.6 v5.6 / 6.16 v4.13 / 4.18 / 5.1 / 6.4 v6.7 / 7.2 v6.18 v5.2 / 5.14 / 6.0 v5.12 / 7.0 提案 (NetDev 0x1a) 提案 (RFC 2025-03) 提案 (LWN 掲載) v4.18 追加→v6.8 削除 v6.1 削除 v6.16 削除 v6.17 削除
8. Linuxネットワークスタック10年の歴史 (抜粋) 取捨選 択 処理場所の選択 資源と制御の共通化 拡張性の向上 v4.0 2015-04 8 cgroup BPF XDP AF_XDP clsact → TCX netkit BTF struct_ops → BPF qdisc kfunc kptr / dynptr / arena CAP_BPF → token → 署名 MSG_ZEROCOPY → mmap io_uring ゼロコピー送信 page_pool → provider devmem TCP io_uring zcrx NAPI の制御 netdev-genl → queue lease extack → ethtool nl → YAML devlink RTNL 分割 (進行中 ) tc / nftables オフロード RACK-TLP BBR TCP ペーシング → EDT DualPI2 / AccECN / ECMP MPTCP (2009 頃から OOT) WireGuard / ovpn kTLS TCP-AO PSP クラウド RDMA 各種 RDMA dma-buf 対応 カーネル内 QUIC UET ドライバ (RFC) rxe/erdma dma-buf bpfilter DECnet DCCP RFC 6675 損失回復コード Ubuntu 14.04 (3.13) '15 RHEL 7.0 (3.10) v5.0 2019-03 '16 Ubuntu 16.04 (4.4) '17 '18 Ubuntu 18.04 (4.15) '19 v6.0 2022-10 '20 RHEL 8.0 Ubuntu 20.04 (4.18) (5.4) '21 '22 Ubuntu 22.04 RHEL 9.0 (5.15) (5.14) '23 v7.0 2026-04 '24 '25 Ubuntu 24.04 (6.8) RHEL 10.0 (6.12) '26 Ubuntu 26.04 (7.0) v4.10 v4.8 / 4.12 / 4.15 / 5.14 v4.18 / 5.4 / 5.8 / 6.6 v4.5 / 6.6 v6.7 / 7.1 v4.18 v5.6 / 6.16 v5.16 v5.19 / 6.9 v5.8 / 6.8 / 7.3 v4.14 / 4.18 v6.0 / 6.1 v4.18 / 5.14 / 6.11 / 6.15 v6.12 / 6.16 v6.15 v5.8 / 5.11 / 5.12 / 6.13 v6.3 / 6.8 / 6.9 / 7.1 v4.12 / 5.2 / 5.6 / 6.3 v4.6 / 5.1 / 5.12 / 5.14 / 6.2 v4.14 / 6.13 / 6.15 / 7.3 v4.6 / 5.1 / 5.3 / 5.5 / 6.3 v4.4 / 4.18 / 6.17 v4.9 v4.13 / 4.20 v6.17 / 6.18 / 7.2 v5.6 / 5.7 / 5.19 / 6.6 v5.6 / 6.16 v4.13 / 4.18 / 5.1 / 6.4 v6.7 / 7.2 v6.18 v5.2 / 5.14 / 6.0 v5.12 / 7.0 提案 (NetDev 0x1a) 提案 (RFC 2025-03) 提案 (LWN 掲載) v4.18 追加→v6.8 削除 v6.1 削除 v6.16 削除 v6.17 削除
9. テーマ 1 拡張性の向上 カーネルを書き換えずに、安全に挙動を変えるにはどうするか DPDK のようにカーネルを迂回せず、スタックの内側に差し込み点を増やす 9
10. テーマ1 拡張性の向上 XDP導入時の議論 (2016) 10 立場 主張 反対 Westphal DPDK 等のユーザー空間スタックの方が開発環境が良 い。HW フィルタも既にある 賛成 Graf パケットがカーネルを離れると、セキュリティ上の判断が できない 賛成 Herbert DDoS 対策だけでも十分な動機。ハードウェア任せにした くない 賛成 Miller 落とす用途では HW フィルタでは足りない 懸念 Sowa ヘルパーが増えると ABI の一部になり、将来の変更を縛 る 折衷 Hemminger 複数のアプローチが共存する余地がある 出典: LWN 708087, LWN 719850 位置づけ XDP は DPDK の代わりではな く、カーネルと協調する高速パス 2017 年の本番報告 Facebook: 3 つの eBPF プログ ラムの連鎖で、IPVS ベースの L4 LB 比 10 倍
11. テーマ1 拡張性の向上 BPFプログラムを差し込む位置: skb の前と後 受信 (RX) NIC RX XDP (native) v4.8 skb 生成 tc ingress cls_bpf / TCX netfilter ルーティング ソケット XDP_REDIRECT AF_XDP ソケット (UMEM) v4.18 generic XDP (v4.12): ドライバ未対応時は skb 生成後に動く。native と generic は同時に有効にならない。 netkit (v6.7): 仮想デバイスの xmit の中で BPF が動く。 送信 (TX) ソケット 11 ルーティング tc egress clsact / TCX qdisc 概念図 (v7.3 時点の構造)。XDP_TX、cpumap・devmap、オフロードされた XDP は省略。 ドライバ NIC TX
12. テーマ1 拡張性の向上 XDP: 「高速パス」から「多様なパス」へ 環境を増やす 出口を増やす デバイスを増やす パケットを増やす • generic XDP (v4.12) • live packet 試験 (v5.18) • cpumap (v4.15) • xskmap (v4.18) • devmap_hash (v5.4) • broadcast (v5.14) • tap (v4.14) • veth (v4.19) • multi-buffer • AF_XDP 対応 (v6.6) 残る課題 • • 12 native XDP の高速パスにはドライバの対応が必要 generic XDP はドライバ非依存だが最適化されていない。
13. テーマ1 拡張性の向上 AF_XDP: カーネル空間のドライバからユーザー空間への出口 カーネル NIC の RX queue 13 ユーザー空間 XDP プログラム (BPF が分類) XSKMAP redirect DPDK との違い ゼロコピーへの道 NIC をカーネルから切り離さず、 分類は BPF が担う。残りはス タックへ流せる。 • • • • v4.18 初版はコピーあり v5.4 unaligned chunk v5.8 バッファ割り当て API v6.6 multi-buffer UMEM + 4 リング fill / rx / tx / completion 注意点 キューの指定と振り分けは管理 者の責任。ナノ秒を数える人向 けの機能。
14. テーマ1 拡張性の向上 BPF: v4.0 から v7.3 までの進化を数字で見てみる 1 → 32 2 → 35 プログラム型 (bpf_prog_type) マップ型 (bpf_map_type) 3 → 212 — → 368 ヘルパー関数 (bpf_*、FN()) 14 kfunc の定義 (__bpf_kfunc) ヘルパーを増やすのをやめ、kfunc に移す方針 数は include/uapi/linux/bpf.h と git grep による(tools/ のセルフテスト用を除く、カーネル本体のみ)。
15. テーマ1 拡張性の向上 BPF のユースケースの発展を 5 つの層で見てみる 層 問い v4.0 v7.3 取り付け点 どこに置けるか ソケットフィルタ 1 つ プログラム型 32 検証器と型 何を書けるか 関数なし・ループなし 関数、有界ループ、BTF 向き 誰が誰を呼ぶか カーネル → BPF のみ struct_ops / kfunc データ 何を持てるか ハッシュ・配列のみ kptr、dynptr、arena 信頼 誰が許すか CAP_SYS_ADMIN CAP_BPF、token、署名 struct_ops は BTF・trampoline に、BPF qdisc は bpf_obj_new に実装上の依存がある。 15
16. テーマ1 拡張性の向上 取り付け点: パケット単位からソケット・cgroup 単位へ 16 版 取り付け点 何を可能にしたか v4.10 cgroup / 軽量トンネル cgroup 階層に付けて子孫へ継承 / dst_input 等に 3 つの型 v4.13 sock_ops 接続のパラメータ (バッファ、SYN の RTO) を BPF が決める v4.14 sockmap ソケットを map に入れ、ソケット間でリダイレクト v4.17 sk_msg sendmsg / sendpage の位置でポリシーを実行 v4.19 sk_reuseport SO_REUSEPORT のソケットを BPF が選ぶ v4.20 flow dissector フロー分類のパスで BPF が動く (netns ごと) v5.7 / v5.9 LSM / sk_lookup セキュリティ政策を BPF で / 受信側のソケット検索を BPF が行う v6.4 netfilter NF_HOOK() の位置で BPF が動く
17. テーマ1 拡張性の向上 BPFユースケースの多様化: BPFプログラムがカーネルの部品に 取り付け点 (XDP, tc) struct_ops (v5.6) kfunc (v5.16〜) カーネルが定めた位置に BPF を 付ける。安定した UAPI。 カーネルの関数ポインタ表を BPF で実装する。最初の利用者 は tcp_congestion_ops。 BPF がカーネル関数を直接呼 ぶ。UAPI の番号も安定性の約 束もない。モジュールも定義でき る。 カーネル カーネル → BPF BPF BPF カーネルの関 数表 BPF が実装する側 BPF qdisc (v6.16) = struct_ops + bpf_obj_new + list/rbtree 17 BPF カーネル関数 BPF → カーネル
18. テーマ1 拡張性の向上 安全にBPFプログラムを動かすために 18 CAP_SYS_ADMIN CAP_BPF v5.8 BPF token v6.8 v4.0 の bpf() はこれを要 求 allow_ptr_leaks を 4 つに 特権プロセスから信頼でき 分け、ネットワーク向けは投 る非特権プロセスへBPFプ 機実行対策つき ログラムのロードを委譲。 BPF FS の userns で検査 署名ローダー v7.3 署名が命令列とメタデータ の凍結内容の両方を覆う 仕様化 変わらない点 BPF の命令セットは 2024-10 に RFC 9669 (Proposed Standard) として発行された。仕様を書くと、実装では当 たり前だった点 (32 ビット即値の符号拡張など) の曖昧さ が見つかる。 検証器の誤りがカーネル全体に影響する点は同じ。もう 一つの防衛線が要る、と発表は述べている。
19. テーマ1 拡張性の向上 TCX (v6.6): tc ingress/egressへの新しい取り付け方式 Meta 「アプリがクラッシュして誰も気づかないと、 BPF は取り付いたまま、落とし続ける」 Cilium 「別の Kubernetes アプリが同じ prio/handle に 取り付け、プログラムを誤って消した」 BPF link 相対順序 revision 所有権を持つ fd。ピン留めしなけれ ば自動で切り離される qdisc-less 優先度の数値でなく BPF_F_BEFORE / AFTER で指定 取り付け点ごとのリビジョンで競合を 検出 なぜ相対順序か: 優先度は衝突するので使いにくい、というレビューの指摘と、systemd の Before= / After= の考 え方 19 出典: e420bed02507 の commit message、bpfconf 2023 (スライドのみ、議論の記録なし)。
20. テーマ1 拡張性の向上 netkit (v6.7): デバイスの中に BPF を置く 1MBあたりの処理時間 (μs) 設計 Pod の送信側 peer の xmit の中で BPF が動く。 プログラムは primary (ホスト側) だけが管理し、 TCX と同じ bpf_mprog を使う。 一度戻され、再び入った • 2026-01-15 net-next に投入 • 2026-01-20 revert (io_uring の作業と衝突) • v7.1 で再投入。v7.3 には AF_XDP 対応あり ホスト自体と同等の 85 µs/MB に達した、と発表は示す 20 測定は発表スライドの図からの読み取り(tcp_mmap、back-to-back、mlx5、MTU 8264、非ゼロコピー)。他の測定による確認なし。
21. テーマ 2 資源と制御の共通化 パケットのメモリと queue を、誰がどう分担するか 設定と観測を、大規模な運用でどう扱うか テーマ 1 の小結: フックと実装の主体が増え、検証と所有権が重要になった 21
22. テーマ2 資源と制御の共通化 メモリ管理をデバイスドライバ固有実装から共通の仕組みへ page_pool v4.18 デフォルト XDP 送信のページ回収のために導入。ドライバごとの 再利用を集約 (v5.14〜) ホストのページ netmem v6.11 devmem TCP v6.12 / 送信 v6.16 page_pool からメモリの型を抽象化。当初は常に page が下にある no-op dma-buf のデバイスメモリ (net_iov)。netlink で queue に bind memory provider v6.15 io_uring zcrx v6.15 プールのメモリの出どころを差し替える汎用フック 22 ユーザーのページ (net_iov)。ifq 登録と refill リング
23. テーマ2 資源と制御の共通化 io_uring ZCRXとdevmem TCP io_uring zcrx と epoll の測定 devmem TCP の設計 仕組み header split。ヘッダはホストへ、ペイロー ドは dma-buf へ DMA。TCP/IP スタック は変えない。 残る制約 header split が必須。unreadable frag は XDP と共存できない。 データ照合あり 23 データ照合なし データ照合あり データ照合なし Kernel Recipes 2024。v6.11 ベース、AMD EPYC 9454、Broadcom BCM957508 200G、HW GRO・IOMMU 有効、単一 TCP 接 続、受信のみ。
24. テーマ2 資源と制御の共通化 Queue APIと NAPI の整備 版 24 変更 内容 v5.8 napi_defer_hard_irqs 割り込み再有効化が 100G NIC のス ループットを約 20% 下げうる v5.11 / v5.12 preferred busy poll / threaded NAPI busy poll の改善 / poll を専用 kthread で実行 v6.3 netdev-genl netdev 用 netlink ファミリ (YAML 仕様 対応) v6.8 / v6.9 queue 情報 / queue 統計 ethtool -S のドライバごとの名前を netlink で統一 v6.13 napi_config NAPI 設定を queue の再構成をまたい で保持 v7.1 queue lease 仮想デバイスの rx queue を物理 NIC の queue に貸す 出典: NetDev 0x18 (スライドのみ)。 Queue API の条件 単一の queue だけを リセット・再構成でき、 そのプールを任意の memory provider に 差し替えられること
25. テーマ2 資源と制御の共通化 netlink関連 extack v4.12 厳格な検証 v5.2 ethtool netlink v5.6 devlink v4.6〜 YAML + netdev-genl v6.3 応答にエラーの詳細と 属性の位置を載せる 検証を属性ごとに設定 可能に ethtool を genetlink に デバイス単位の管理。 SF、rate などへ拡張 仕様から UAPI・文書・ 検証表を生成 動機 (NetDev 0x17) デバイスの設定が ethtool、sysfs、tc、devlink、netfilter、ip、bridge、ソケットオプションに散らばって増え続けて いる。次にモデル化する対象はqueue、NAPI、page pool。 25 出典: NetDev 0x17 (スライドのみ)。YAML は netlink を使うための必要条件ではない。
26. テーマ2 資源と制御の共通化 RTNL: 9 年かけた段階的なグローバルロックの排除 2017 v4.14 v6.13 v6.15 v7.3 NetDev 2.2 DOIT_UNLOCKED per-netns RTNL デバイスごとのロック 保持時間が数百 ms の 例 ハンドラが抜ける道 namespace ごとに分解 netdev インスタンスロッ ク namespace をまたぐ 削除 別 netns のデバイスを 委譲 v7.3 の対象: namespace をまたぐデバイス 3 種 対のデバイス トンネル 積み重ね netkit、veth、vxcan bareudp、geneve ipvlan、macvlan グローバルな RTNL はまだ残っている (最後に外す計画) 26 v6.13〜v7.3 が 2017 年の発表に応えたとする記述はcommit message にない (問題の同一性による整理)。
27. テーマ2 資源と制御の共通化 オフロードとDrop Reasonの観測 オフロード : 共通表現の上に載せる 観測: 「落ちた」から「なぜ」へ 版 内容 版 内容 v5.1 flow_rule: flower のマッチ表現を切り出す v5.4 drop_monitor の packet alert v5.3 nftables の HW オフロード v5.17 kfree_skb_reason(): 捨てる理由を渡す v5.5 flowtable の HW オフロード v6.4 サブシステムごとの理由 v6.3 hardware miss: 一部だけオフロード v7.1 qdisc の drop 理由 (handle・parent 等) ct アクションは完全にはオフロードできない。新しい接続 はソフトウェアで処理し、引き継ぐ設計が要る。 27 drop_monitor や eBPF から、skb を捨てた理由を参照で きる。 Tool - pwru: “Packet, where are you?” by Isovalent - retis by Red Hat Drop reason - SKB_DROP_REASON_NETFILTER_DROP - SKB_DROP_REASON_TCP_CSUM
28. テーマ 3 処理場所の選択 輻輳制御、暗号、新しいプロトコル、RDMA を、 カーネルの中、ユーザー空間、NIC のどこに置くか テーマ 2 の小結: メモリ・queue・設定・観測を共通の対象にし始めた 28
29. テーマ3 処理場所の選択 TCP関連 損失の検出 輻輳制御と送信間隔 ECN と AQM • RACK v4.4: 順序・数でなく時 間 • RACK-TLP は 2018 年から 既定 • RFC 6675 のコードは v6.17 で削除 • BBR v4.9: 帯域と RTT のモ デル • TCP 自身のペーシング v4.13 • EDT モデル v4.20 • AccECN v6.18 • DualPI2 v6.17 (L4S 型。輻輳 制御でなく qdisc) • ECMP の経路選び直し v7.2 BBR → 内蔵ペーシング は歴史的な動因 BBRはペーシングのためにtcスケジューラsch_fqが必要だが、必須にするのは現実できではない AccECN 29
30. テーマ3 処理場所の選択 処理する場所は性能効率/歴史的な事情/実装の容易さに応じて... 30 機能 control plane / handshake data plane 状態 MPTCP カーネル カーネル マージ v5.6 WireGuard カーネル カーネル マージ v5.6 kTLS ユーザー空間 カーネル / NIC マージ v4.13 ovpn (OpenVPN DCO) ユーザー空間 カーネル マージ v6.16 PSP (鍵交換は規定せず) NIC が鍵を導出 マージ v6.18 QUIC ユーザー空間 ユーザー空間が主流 カーネル内は提案
31. テーマ3 処理場所の選択 MPTCP が 11 年遅れた理由 よくある説 ミドルボックスが拒む 別の位置の制約。fork も出荷されていた 実際の主因: fork(最初のout-of-tree実装)がひどかった 21k 行 fork の全体 RFC 8684 (v1) を待った v1 対応の取り込みは RFC 発行 (2020-03) より 前 2.5k 行 TCP/IP コアの変更 upstream するには作り直し: 「MPTCP ソケット」という別概 念 + TCP ULP upstream の条件 既存の TCP に影響せず、性能の退行がなく、保守でき、無効化でき、ユーザー空間から拡張できること (path manager v5.7・v5.19、scheduler v6.6 が拡張点) 31 出典: Kernel Recipes 2026 (スライド 22〜25)、LPC 2019、torvalds ツリーの 2 つの commit。
32. テーマ3 処理場所の選択 暗号: handshake は外、data planeはカーネルと NIC へ 32 kTLS v4.13 NIC オフロード v4.18 handshake upcall v6.4 対称鍵暗号だけカーネル。 handshake はユーザー空間 送信側の暗号化・認証を NIC カーネル自身が TLS の利用 に 者 (NFS、NVMe/TCP) に PSP v6.18 NIC が接続ごとの鍵を持たな い設計 PSP の議論 周辺 UDP カプセル化・片方向・AES-GCM のみ。IETF が標 準化を断った経緯から異論が出たが、反論は「実装した HW が既にある」。 TCP-AO (v6.7): ソケットごとに鍵を設定。v7.2 で非 RFC アルゴリズムを削除。IPsec IP-TFS (v6.14): 小パケットを 集約。 出典: LWN 980430、各 commit message。
33. テーマ3 処理場所の選択 提案 QUIC: カーネルの外で普及、カーネル内実装は議論中 ユーザー空間 TLS の handshake アプリ: GnuTLS カーネル内の利用者 : tlshd カーネル パケット処理・輻輳制御・損失回復 フロー制御・ペーシング・経路管理 IPPROTO_QUIC (IPPROTO_MPTCP と同じ拡張の型 ) カーネルに持つ理由 (提案者) カーネル内の利用者 (SMB、NFS)、POSIX ソケットのモデル、ALPN の振り分け、NIC の暗号オフロードの見通 し。ユーザー空間に置く理由も認めたうえでの混成設計。 33 出典: NetDev 0x1a (2026)「Linux QUIC」。v7.3 のツリーに net/quic は存在しない。
34. テーマ3 処理場所の選択 RDMA と netdev: 統合ではなく共有 dma-buf (デバイスメモリの共通の表現 ) netdev RDMA devmem TCP v6.12: dma-buf を rx queue に bind。データは skb / net_iov で運ぶ import v5.12、export v7.0。対応ドライバは 1 → 6 (mlx5、bnxt_re、efa、ionic、irdma、mana) データパスは別のまま (verbs の queue pair と socket / skb)。共有されたのはメモリ資源のインターフェース。 34 概念図。rxe・erdma の dma-buf 対応と、netkit を介する rxe は提案 (v7.3 のツリーにコードなし)。
35. テーマ3 処理場所の選択 AI の通信: ソケット対 RoCEv2 ソケット 1 フロー 35 215〜220 Gbps ソケット 2 フロー 397 Gbps RoCEv2 1 フロー 392 Gbps ソケット側 RDMA が避けるもの 提案 (未マージ) 単一フローで受信側の softirq が 100%、送信側 60% skb の生成、システムコール、匿名 バッファ TCP を信頼性に残し、データパス を queue pair へ (tcp_bth) NetDev 0x19 (2025)、同一の ConnectX-7 (400G)。特定条件の参考値で、共有の根拠ではない。ソケット側は非現実的な最適化 設定を含む。
36. テーマ3 処理場所の選択 RDMA の周辺: UET と SMC-R UET 提案 • 既存の RDMA を批判: マルチパスなし、順序保証 が必須、go-back-N、DCQCN は脆い • UEC は 80 社以上 • 2025-03 RFC: PDS のソフト実装 (RUD)。仕様 は固まらず、HW も存在しない SMC-R マージ • ソケットのまま RDMA を使う (v4.11) • netdev 経由で入り linux-rdma には未投稿。 RDMA 側が事後に異論 • v5.17 TCP ULP、v6.11 IPPROTO_SMC、v6.19 BPF の handshake フック SMC-R の論点 新しい API を足したこと、IPv6 未対応、メモリ全体への読み書きを開くセキュリティ上の問題。サブシステムをまたぐ機能の レビューを誰が持つかの問題でもあった。 36 出典: NetDev 0x18、LWN 1013363、LWN 723070。v7.3 のツリーに drivers/ultraeth はない。
37. 終章 採用と削除 Linux は何を受け入れ、何を拒否・削除してきたか 何が未決か テーマ 3 の小結: 境界は機能ごとに別の答えで、共有は統合ではない 37
38. 終章 採用と削除 削除された機能 38 版 対象 commit message が書く理由 v4.12 tcp_tw_recycle (4396e46187ca) そもそも機能していなかった (NAT 配下のユースケースで元々壊れ ていた) v5.11 WiMAX (f54ec58fee83) 利用者がない v6.1 DECnet (1202cdd66531) 2010 年から orphaned v6.8 bpfilter (d2ba09c17a06, 98e20e5e13d2) iptablesのルールをbpfに変換する機能。使えないままで混乱を招い ていた。 v6.16 DCCP (2a63dd0edf38) 2021 年に orphaned、最近はsyzbotの遊び場？ v6.17 RFC 3517/6675 のコード RACK-TLP が 2018 年からデフォルトになり使われなくなった v7.1/7.2 ATM (6deb53595092) / AppleTalk 使われない / レビューされないしAI自動生成の修正爆弾が来る v7.2 TCP-AO のRFCに載っていないア ルゴリズム (5eb0cfedb258) 標準化されておらず、鍵導出も定まらない (1c120191dcec) (8a398a0c189e) DCCP の削除の別の理由 : TCP ソケットのキャッシュ局所性の改善が DCCP に阻まれていた (NetDev 0x19)
39. 終章 採用と削除 mergeとrejectの判断軸 39 既存の処理に影響しない UAPIを無駄に増やしすぎない MPTCP の条件: 既存の TCP に影響せず、 regressionがなく、無効化できる。fork はこれを満た さなかった ヘルパー(UAPI)から kfunc, struct_opsへ。2016 年 に Sowa 氏が ABI の固定を懸念 標準化との関係 継続的なメンテナンスが可能であること PSP は IETF が標準化を断った経緯で異論が出た。 BPF の命令セットは逆に IETF で標準化へ 削除理由の大半はメンテナの有無に帰着する。 MPTCP も upstream には作り直しを求められた
40. 終章 採用と削除 議論中のトピック 40 論点 区分 現状 カーネル内の QUIC 未マージ 提案。TLS の handshake はユーザー空間に残す混成設計 RDMA と netdev の関係 設計上の未決 dma-buf で共有は進んだが、データの経路は別。UET の位置づ けは提案段階 BPF の署名と信頼 運用未確認 署名の対象の設計は v7.3 で進んだ。運用と LSM の統合は未確 認 グローバルな RTNL 実装途上 分割は進んだが、まだ残っている BPF の「任意のアルゴリズム」 実装状況未確認 arena と cond_break で道は開いた。任意のロック等は未確認 署名の運用・LSM 統合と、BPF の課題の実装状況は本調査では未確認。
41. 終章 結論 最後に: 様々な仕組みを発展させてきた10年 テーマ 増えた選択肢・共通化 それを支える制御・管理・判断 課題 拡張性の向上 XDP・AF_XDP・TCX netkit・struct_ops verifier、BPF link、token kfunc の不安定性 ドライバ依存 資源と制御 memory provider queue API・netlink queue 統計、RTNL 分割 drop reason XDP と共存不可 RTNL は未完了 処理場所 MPTCP・kTLS RDMA と netdev 分業、dma-buf の共有 共有は統合でない QUIC は提案 採用と削除 MPTCP の作り直し DCCP などの削除 既存に影響しない、保守できる “skb or bypass” ではなく、用途ごとの共存の基盤へ 用途ごとの複数の処理が共存でき、それらをスケーラブルに制御する仕組みを持つ基盤 41
42. ご清聴ありがとうございました 議論したい点 ・カーネル内の QUIC は必要か ・RDMA と netdev の接点はどこまで共有すべきか ・次の 10 年、共有すべき境界と分離すべき境界はどこか 42
43. 付録 付録: 主な出典 種別 出典 カーネル git の commit message、kernel Documentation (Linux v7.3 のツリー) BPF bpfconf 2022 / 2023 / 2024 (LSF/MM/BPF)、LPC 2018 / 2019 ネットワーク NetDev 0x17 / 0x18 / 0x19 / 0x1a、Kernel Recipes 2024 / 2026 LWN 708087、719850、723070、750845、980430、989494、1013363 ほか LWN の解説記事は取材者による要約を含み、一次資料とは区別している。数値は資料に書かれた値の転記。 43
44. 付録 付録: 出典詳細 — LWN 44 記事 タイトル 種別 lwn:708087 Debating the value of XDP 解説記事 (Corbet) lwn:719850 New approaches to network fast paths 寄稿記事 (Beaupré) lwn:750845 Accelerating networking with AF_XDP 解説記事 (Corbet) lwn:723070 The trouble with SMC-R 解説記事 lwn:817737 RDMA: Add dma-buf support RFC の cover letter lwn:980430 Offload-friendly network encryption in the kernel (PSP) 解説記事 lwn:989494 Device Memory TCP パッチ cover letter (v25) lwn:1013363 Ultra Ethernet driver introduction RFC の cover letter lwn:1064824 / 1078512 rxe、erdma の dma-buf 対応 パッチ投稿 (提案) 解説記事・寄稿記事は取材者・寄稿者による要約を含む。 cover letter の掲載は投稿者本人の文章で、投稿者の主張として読む。
45. 付録 付録: 出典詳細 — カンファレンス 45 会議 セッション 会議 セッション bpfconf 2022 Comprehensive BPF kfunc support NetDev 2.2 RTNL mutex, the network stack big kernel lock bpfconf 2022 BPF program signing and extended BPF policies NetDev 0x17 Netlink APIs to Expose/Configure Netdev Objects bpfconf 2023 Generic BPF multi-attach API & initial implementation for tcx and XDP NetDev 0x17 TLS handshake for in-kernel consumers bpfconf 2024 Modernize BPF for the next 10 years NetDev 0x18 Devmem TCP & io uring zero copy bpfconf 2024 BPF IETF standardization update & roadmap NetDev 0x18 Introduction to Ultra Ethernet Consortium 1.0 LPC 2018 Scaling Linux Traffic Shaping with BPF NetDev 0x19 AI Networks - RoCEv2 and the role of "netdev" LPC 2019 Multipath TCP Upstreaming NetDev 0x19 State of the union in TCP land Kernel Recipes 2024 Efficient zero-copy networking using io_uring NetDev 0x1a Linux QUIC: Bringing a Modern Secure Transport into the Kernel Kernel Recipes 2026 MPTCP: when one path is not enough NetDev 0x1a Accelerating Software RDMA (RXE) with Netkit and Devmem NetDev 0x1a TCP State of the union (2026)