XDPとAF_XDPによる高速パケット処理

なぜ「ドライバ直後」で処理するのか

DDoS防御やロードバランサのように大量のパケットを高速に裁く用途では、1パケットあたりに固定でかかるコストが致命傷になります。ネットワークスタックのカーネル内データパスで見たとおり、受信パケットはまず struct sk_buff（skb）という制御構造に包まれ、GRO・IP・TCPと層を上っていきます。skbの確保・初期化だけでもパケット1個あたり数百ナノ秒級のコストがかかり、捨てるだけのパケットにこれを払うのは純粋な無駄です。

XDP（eXpress Data Path）は、この無駄を処理地点を前倒しすることで消します。NICドライバが受信したパケットを、skbを割り当てる前——ドライバのNAPI poll内、DMAで届いた生のバッファがまだRXリング上にある段階——でeBPFプログラムに渡すのです。ここで「捨てる」と決めれば、skbは一度も作られません。本記事は、このXDPのフックと4つのアクション、ゼロコピーを担うAF_XDP、そしてDPDKとの設計思想の違いを内部から解剖します。

XDPのフック位置とコンテキスト

XDPはeBPFのフックの一種で、検証器を通った安全なプログラムだけがアタッチされます。普通のeBPFと違うのは、渡されるコンテキストが豊かな sk_buff ではなく、ごく薄い struct xdp_buff（生パケットの先頭・末尾ポインタとメタデータ領域だけ）である点です。skbがまだ存在しないので、当然です。

実行モードは3段階あり、どこまで前倒しできるかが変わります。

本命はネイティブXDPです。ジェネリックモードはskbができた後に呼ばれるため、XDP_DROP でも結局skb確保コストを払っており、XDPの速度的旨味はほとんどありません。動作確認用のフォールバックと割り切るべきものです。

4つのアクション：DROP/PASS/TX/REDIRECT

XDPプログラムは戻り値（整数）1つでパケットの運命を決めます。これがXDPの表現力の核です。

• XDP_DROP：即座に破棄。skbを作らずRXバッファを再利用リングへ戻すだけなので、最速の捨て方です。DDoS防御の本質はここにあり、不正パケットをライン速度で落としても正規トラフィックの処理に影響しません。
• XDP_PASS：通常のスタックへ流す。ここで初めてskbが割り当てられ、カーネル内データパスの通常経路に合流します。XDPで触らないパケットの既定の行き先です。
• XDP_TX：受信したNICからそのまま送り返す。パケット内容を書き換えてから返せば、ICMPの即応答や単純なリフレクタ・簡易ロードバランサが、スタックを一切通さず1枚のNIC内で完結します。
• XDP_REDIRECT：別のNIC、別のCPU、あるいはAF_XDPソケットへパケットを横流しする。後述のゼロコピー・ユーザー空間処理の入口がこれです。リダイレクト先はeBPFマップ（devmap・cpumap・xskmap）で指定します。

NIC DMA → RXリング → ドライバpoll → [XDPプログラム]
                                       │
        ┌──────────────┬──────────────┼───────────────┐
     XDP_DROP       XDP_PASS        XDP_TX        XDP_REDIRECT
     破棄(再利用)   skb作成→         同NICへ         devmap/cpumap/
                   通常スタック     送り返す        xskmap経由で横流し

AF_XDP：ゼロコピーでユーザー空間へ

XDP_DROP や XDP_TX はカーネル内で完結しますが、パケットをユーザー空間アプリで処理したいことも多くあります（独自プロトコル終端、高速プロキシなど）。従来これは recv() のたびにカーネルバッファからユーザーバッファへコピーが入りました。AF_XDP（Address Family XDP）はこのコピーを消すソケット型です。

仕組みの中心は UMEM と4本のリングです。

• UMEM：ユーザー空間が確保し、カーネルへ登録した連続メモリ領域。等サイズの「チャンク」に区切られ、各チャンクがパケット1個分の枠になります。NICのDMAはこのUMEMへ直接書き込むため、ここがゼロコピーの肝です。
• Fillリング：ユーザー → カーネル方向。「このチャンクは空いている、ここに受信していい」とカーネルへ渡す。
• RXリング：カーネル → ユーザー方向。「このチャンクに受信した」とディスクリプタ（UMEM内オフセットと長さ）を返す。
• TX/Completionリング：送信用の対。ユーザーが送るチャンクをTXに積み、送信完了したチャンクをCompletionで回収する。

受信の流れはこうです。アプリは空きチャンクをFillリングへ補充しておく。NICがパケットをDMAでそのUMEMチャンクへ書き込み、XDPプログラムが bpf_redirect_map() でxskmap経由そのAF_XDPソケット（XSK）へREDIRECTする。カーネルはRXリングにディスクリプタを1本積むだけで、データ本体は一度もコピーされません。アプリはRXリングのディスクリプタが指すUMEM内のパケットを直接読みます。

[ユーザー空間]  UMEM（NICのDMA先）   Fill │ RX │ TX │ Completion
                   ▲                    │     ▲    │      ▲
                   │ DMA write          補充  受信  送信   完了回収
[カーネル/NIC]  NIC ──── XDPプログラム ── XDP_REDIRECT(xskmap) ──→ XSK

リング操作は共有メモリ的なロックレス設計で、プロデューサ/コンシューマがそれぞれ自分側のインデックスだけを進める単一生産者・単一消費者リングです。これによりシステムコールなしでパケットを受け渡せます（ウェイクアップ時のみ sendto/poll を使う）。

DPDKとの設計差：専有か、共存か

ユーザー空間高速パケット処理の代表格にDPDK（Data Plane Development Kit）があります。XDP/AF_XDPと目的は近いものの、設計思想が根本的に異なります。

DPDKはカーネルを丸ごと迂回します。NICをカーネルドライバから引き剝がしVFIO等でユーザー空間に専有させ、専用コアをビジーポーリングで回し続けることで、割り込みもコンテキストスイッチもない極限のスループットを得ます。代償は、そのNICとCPUコアがその用途に占有されること、そしてカーネルの恩恵（既存のTCP/IP、ツール群、隔離）を自前で再実装する必要があることです。

XDP/AF_XDPは逆にカーネル内に留まります。ドライバはカーネルのまま、XDPは検証器に守られたeBPFとして動き、裁ききれない/裁きたくないパケットは XDP_PASS で通常スタックへ戻せます。同じNICで高速パス（AF_XDP）と通常のTCP接続を同居させられ、CPUもアイドル時にはNAPIの割り込み緩和で省けます。スループットの絶対上限はDPDKに譲る場面があっても、既存システムへの統合性・安全性・運用の柔軟性で勝ります。

まとめ