# eBPFマップ ## 定義 eBPFマップは、[[eBPF]]プログラムにデータ保存とユーザ空間との通信の能力を提供するカーネル内データ構造である。array・hash・per-cpu array・per-cpu hash・ring buffer・perf buffer・queue・stackなど複数の型が存在し、eBPFプログラム間、あるいはeBPFプログラムとユーザ空間プログラムの間でデータを受け渡す主要な手段として機能する。eBPFプログラムの機能性がこれまでの研究・実務の焦点だったのに対し、その性能特性は長らく体系的に調べられてこなかった。(Source: [[@2024__eBPF'24__Understanding Performance of eBPF Maps]]) ## 横断的知見 - 本conceptは現時点で単一ソース([[@2024__eBPF'24__Understanding Performance of eBPF Maps]])のみに基づく。同ソースが示す「メモリフットプリントとキャッシュホット性がeBPFマップのオーバーヘッドの主要因である」という知見は、[[eBPF]]概念ページが蓄積してきた「情報を最上流(カーネル)で絞る」という設計指針(LogReducer・go-conntracer-bpf・cache_ext等)と接続しうる——マップアクセス自体のオーバーヘッドが値サイズとキャッシュ状態に強く依存するという事実は、カーネル内で扱うデータ量を絞る設計判断(小さな値サイズを保つ、事前確保済みhashマップを使う等)が実装レベルでも性能上正当化されることを示唆する。ただしこの接続は今のところ単一ソースからの推論であり、複数ソースの突き合わせによる横断的知見としてはまだ確立していない。 ## 未解決の問い - [[Linuxカーネルインタフェース]]が提起した「eBPFマップやBPF_PROG_QUERYはNetlinkの4性質フレームワーク(可搬性・イベント通知・拡張容易性・大規模転送)のどこに位置づけられるか」という問いに対し、本ソースのring buffer/perf bufferの性能比較(reserve+submit方式によるメモリコピー削減)は「大規模データ転送」軸の実証的な性能データを提供しうる。両ページを突き合わせて具体的な位置づけを行う余地がある。 - per-cpu hashマップの「新規キー挿入時に全CPU分の値領域をゼロ初期化する」という設計は、[[eBPF]]の他の性能重視の設計判断(sched_ext・cache_extの「情報を最上流で絞る」パターン)と対照的に、CPU数のスケールとともにオーバーヘッドが増大する可能性がある。マルチソケット・多コア環境(数十〜百コア級)でこの初期化コストがどう振る舞うかは本ソース(2ソケット×10コア)の範囲を超えており未検証。 - 本ソースの測定はLinux 6.0.1・x86-64・JIT有効という単一環境に限定されている。他のカーネルバージョン、ARM等の他アーキテクチャ、SmartNICオフロード環境でeBPFマップの性能特性がどう変化するかは未調査。 - eBPFマップの並行アクセス時のオーバーヘッド(本ソースはベンチマークシステム自体は対応するが、紙幅の都合で結果を割愛)、およびユーザ空間からのeBPFマップアクセスのオーバーヘッドは、本ソースでは実測されておらず、著者ら自身がfuture workとして残している。 ## 関連 - ソース: [[@2024__eBPF'24__Understanding Performance of eBPF Maps]] - 概念: [[eBPF]] / [[BPF]] / [[Linuxカーネルインタフェース]] / [[カーネル内VM]] ## 出典 - [[@2024__eBPF'24__Understanding Performance of eBPF Maps]](array・hash・per-cpu変種・ring/perf buffer・queue/stackの網羅的性能ベンチマーク。メモリフットプリントとキャッシュホット性が主要因。「volume discount」特性)