# XDP ## 定義 XDP(eXpress Data Path)は、NIC ドライバ層で eBPF プログラムを実行し、`skb` の割り当てと通常のネットワークスタック処理より前にパケットを処理する Linux のネットワークフックである。 プログラムの戻り値により、通常のソケット経路へ渡す`XDP_PASS`、NIC から送出・転送する`XDP_TX`/`XDP_REDIRECT`、その場で破棄する`XDP_DROP`を選ぶ。(Source: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) XDP の設計原論文([[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]])は、この仕組みを DPDK のようなカーネルバイパスの**対極**のアプローチとして位置づける。ネットワークハードウェアの制御をカーネルの外へ移すのではなく、性能に敏感なパケット処理操作をカーネルの中に移し、OS ネットワーキングスタックが処理を始める前に実行することで、カーネル・ユーザ空間境界を除去する利点を保持しつつカーネルがハードウェアの制御とセキュリティ境界を保持する。XDP システムは (1) XDP ドライバフック、(2) eBPF 仮想マシン、(3) BPF maps、(4) eBPF verifier の4コンポーネントで構成される。(Source: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] §3) ## 原論文の性能評価(2018年時点のベースライン) 単一コアのパケットドロップ性能は XDP が24 Mpps、DPDK(testpmd, 18.05)が43.5 Mpps、Linux ネットワーキングスタックが raw モードで4.8 Mpps・conntrack使用時1.8 Mppsだった。XDPは regular networking stack の最速モードに対して5倍の改善を示したが、DPDKには届かない。この差は主にドライバ側の関数呼び出し回数(mlx5ドライバで10回/パケット)に起因すると分析されている。実世界ユースケースでは、ソフトウェアルーティングで Linux 比 2.5〜3倍、[[Katran]] ロードバランサで Linux IPVS 比 4.3倍、[[Cloudflare]] の Gatebot を模した DDoS 緩和で 19.5 Mppsの攻撃トラフィックまで安定したTCPトランザクション性能を実証した。(Source: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] §4, §5) ## XDPerf における送信 XDPerf は、`BPF_PROG_TEST_RUN` の live frames mode で XDP プログラムをカーネル内ループから繰り返し実行し、`XDP_TX` でパケットを送出する。 通常の socket 送信がパケットごとに `sendmsg()` を呼ぶのに対し、live frames mode は一つのバッチシステムコールと per-CPU スレッドへ処理を集約する。(Source: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) ## 関連概念との境界 XDP は DPDK のように NIC をユーザー空間が完全占有する方式ではない。 NIC の既存ドライバを維持したままドライバ層の早期パスを使うため、DPDK 系より導入時の責任境界を小さくできる一方、性能は XDP 対応ドライバ、カーネル、NIC キュー、IOMMU 設定に依存する。(Source: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) ## 横断的知見 - **XDP は「カーネルを迂回する」より「カーネル内の早期パスを使う」設計である**: XDPerf は未変更の upstream ドライバを保ったまま DPDK 級の packets per second を狙い、LUNA や DPDK のような完全なユーザー空間 NIC 制御とは異なる責任境界を取る。([[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]], [[@2023__USENIX ATC__Deploying User-space TCP at Cloud Scale with LUNA]]) - **XDP の送信性能とトラフィック表現力は別層へ分けられる**: XDPerf は XDP/eBPF をパケットごとの送信経路に置き、Wasm プラグインを起動時のパケット定義に置く。eBPF プログラムをプロトコルごとに増やさず、柔軟性と hot path の性能を分離する構成である。([[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]], [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]]) - **XDP の実効性能はパケット処理だけでなく DMA とキュー構成に左右される**: XDPerf の測定では IOMMU の IOTLB flush によるロック競合で 42.3 Mpps に落ちたが、`iommu=pt` で 115.8 Mpps へ戻った。veth でも 1 queue の 7.4 Mpps に対し 8 queues で 61.3 Mpps となり、XDP の速いプログラムだけでは線速を保証しない。([[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]], [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) - **「カーネルバイパスの対極」という設計思想は、2018年の原論文で既に明示的に定式化されていた**: XDP 設計論文は、DPDK が「ハードウェア制御をカーネルの外へ移す」のに対し、XDP は「性能に敏感な処理をカーネルの中に移す」ことで対極のアプローチを取ると述べる。2026年時点の XDPerf が「XDP は DPDK ほど NIC を占有せず未変更ドライバで動く」と説明する構図は、原論文が2018年の時点で既に示していた設計思想の直接的な延長であり、8年間 XDP の基本的な位置づけ自体は変わっていないことが分かる。([[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]], [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]]) - **XDP と DPDK の性能差はマイクロアーキテクチャレベルの関数呼び出しコストまで定量化されていた**: 原論文は2018年時点でXDP(24 Mpps, 41.6 ns/パケット)とDPDK(43.5 Mpps, 22.9 ns/パケット)の差18.7 nsのうち13 nsがmlx5ドライバの関数呼び出し回数差(10回 対 1回)に起因すると分析し、DMA関連呼び出し4つの除去で29 Mppsまで改善することを実験的に示した。この「ドライバの関数呼び出しオーバーヘッドが性能差の主要因」という原論文の分析は、その後のXDP実装(i40eドライバ等)がNICハードウェア限界までフル性能を達成した進展の技術的背景を説明する。([[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]]) - **eBPF verifier のレジスタ状態追跡アルゴリズムは、XDP のパケット境界チェックという具体的な安全性要求から動機づけられていた**: 原論文は verifier が `data_end` ポインタとの比較によるパケットデータ境界チェック、マップ定義に基づく値サイズチェック、NULLチェック済みマップルックアップ結果の要求を静的に検証する仕組みを詳述する。この「境界外メモリアクセスの防止」という verifier の中核機能は、XDP がカーネル内で直接パケットデータへアクセスするという設計要求から生まれたものであり、[[eBPF]] concept が集約する verifier の一般論(§3.4)に、XDP という具体的な適用ドメインからの設計動機を与える。([[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]]) ## 未解決の問い - `BPF_PROG_TEST_RUN` live frames mode の性能を、NIC 世代、XDP native/generic mode、IOMMU、veth のキュー数を含む共通ベンチマークで比較できるか。 - XDP の verifier とドライバ固有実装の差を、XDPerf の multi-kernel CI のように NIC・カーネル組み合わせまで含めて自動検証できるか。 - 差分テンプレートによる可変パケット生成を、可変長 payload、複雑なトンネル、SRv6 のような依存チェックサムを持つプロトコルへどこまで一般化できるか。 - XDP の早期パス、DPDK、ユーザーレベル TCP スタックを、NIC 占有、保護境界、ドライバ再利用性、Mpps、運用復旧性の同一指標で比較できるか。 - 原論文(2018年、Linux 4.18時点)が課題として挙げた QoS 機構の欠如・ステートフルトランスポートプロトコルへの拡張・AF_XDPのゼロコピー未成熟は、2026年時点でどこまで解消されているか。一次資料でその後の進展を追う価値がある。([[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] §6) ## 関連 - ソース: [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]] / [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] - エンティティ: [[XDPerf]] / [[Linux]] / [[wazero]] / [[Katran]] / [[Cilium]] / [[Cloudflare]] / [[Toke Høiland-Jørgensen]] - 概念: [[eBPF]] / [[BPF]] / [[RSS（Receive Side Scaling）]] / [[カーネルバイパスネットワーキング]] / [[WebAssembly]] / [[DPDK]] ## 出典 - [[@2026__KubeCon Japan Community Day__XDPerf - A High-Performance Traffic Generator Built with WASM and eBPF]] — XDP フック、live frames mode、XDPerf の送信経路・性能測定。 - [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]] — XDP の設計原論文。4コンポーネントのアーキテクチャ(ドライバフック・eBPF VM・BPF maps・verifier)、DPDK比較性能評価(24 Mpps対43.5 Mpps)、ソフトウェアルーティング・DDoS緩和・ロードバランシングの実世界ユースケース。 - [[@2023__USENIX ATC__Deploying User-space TCP at Cloud Scale with LUNA]] — DPDK とユーザーレベル NIC 制御の比較対象。 - [[@2024__SIGCOMM__NetEdit - An Orchestration Platform for eBPF Network Functions at Scale]] — eBPF ネットワーク機能の制御・ライフサイクルとの対比。