eBPFで変わること、変わらないこと

eBPFは選択されたカーネル機能を拡張する仕組みであり、カーネルモジュール全般を置き換えるものではありません。プログラムは種類、アタッチ先、対象カーネルが許可するヘルパーや機能に制約されます。ロード時に検証器は、初期化済みのレジスターやスタック、ポインターの型と範囲、コンテキストごとのアクセス、ヘルパーの引数などを確認します。合格はこれらの検証条件を満たしたことを示しますが、アプリケーションの方針が正しいことや、実行時の問題がすべて起こらないことを証明するものではありません。対応範囲とロード結果は、プログラム種別、権限、カーネルの版や設定によって異なります。

新しいカーネルでは検証条件を満たす一部の有界ループを扱えますが、どのループも、どのカーネルでも受理されるわけではありません。複雑度の上限や状態解析によって拒否される場合もあります。導入先と同じ条件のカーネルでロードし、検証ログを確認してください。JITはアーキテクチャ、設定、ポリシーに応じてバイトコードをネイティブ命令に変換しますが、それだけで性能目標の達成が保証されるわけではありません。

アタッチ先によって観測できる内容が変わる

トレース用プログラムでは、tracepoint、kprobe、uprobeなどから目的に合うアタッチ先とプログラム種別を選びます。特定のアタッチ先がすべてのカーネルに存在し、同じ意味を持つとは限りません。対象カーネルのBTF、対応するプログラム種別・ヘルパー、必要な権限を確認します。BPF mapもすべてロック不要の交換表として動作するわけではありません。アクセスや並行性の意味はmap種別で異なるため、共有カウンターの更新、ユーザー空間での消費速度、イベント欠落を分けて確認します。

XDPには3つのモードがあります。native XDPは対応ドライバーの早い受信経路、generic XDPはネットワークスタックに入った後、offloadは対応NICのハードウェアで実行されます。CiliumのXDP加速も設定とデバイス対応に依存します。XDPで処理されたパケットは、経路の後段に置いたtcpdumpに現れない場合があります。キャプチャに見えないことだけで、パケットが処理されなかったとは判断できません。

仮想事例：期待したパケットがキャプチャに見えない

以下は手順を示すための仮想例であり、実測結果ではありません。Ciliumノードのtcpdumpで、期待したNodePortパケットを見つけられない状況を想定します。

確認調べる証拠解釈と次の確認
1. アタッチ状態ip linkのXDP状態、CiliumのXDP状態、インターフェースのドライバーモードと対象デバイスを確認します。想定と違えば、まず設定とドライバー対応を調べます。
2. キャプチャ位置パケット経路上のtcpdumpの位置とXDPカウンターnative XDPは後段のキャプチャより先に処理できます。XDPの前後に合うカウンターや観測点を選びます。
3. プログラムのロードプログラム種別、検証ログ、カーネル版、権限拒否は検証条件または未対応機能による可能性があります。最初に拒否された箇所を対象カーネルの対応状況と照合します。
4. 負荷と欠落処理量、CPU、mapの競合、リングバッファの欠落と消費遅延イベントが足りない場合、単にバッファを大きくする前に生成量、消費量、イベントサイズ、収集コストを比較します。

まず観測したい問いを一つに絞り、最小限のフックを選びます。導入先と同等のカーネル環境でロードし、カウンターと欠落を確認してください。そのうえで代表的な負荷において、導入前後のCPU使用量と遅延を比べます。この記事ではカーネルへのロード、Ciliumの導入、性能ベンチマークを実行したとは主張していません。

資料：Linux eBPF検証器、Linux BPF設計Q&A、Cilium XDPプログラム種別、Cilium XDP加速