📚 课程目录第3章 eBPF内核基础

3. eBPF内核基础：程序类型、Map机制、验证器与JIT编译对CPU/内存的影响

在Cilium数据面中，eBPF是核心执行引擎。理解eBPF程序类型、Map机制、验证器与JIT编译对CPU和内存的具体影响，是进行资源画像与联合优化的前提。本章从内核基础出发，逐一拆解这些组件在数据路径上的资源消耗特征。

eBPF程序挂载点决定了它在网络栈中的位置，进而影响CPU开销和内存访问模式。Cilium主要使用以下三种类型：

程序类型	挂载位置	CPU开销特征	内存访问模式	典型场景
XDP	网卡驱动层（最早）	极低（无skb分配，无协议栈）	直接DMA内存，无拷贝	DDoS防护、负载均衡、包过滤
TC	内核协议栈入口/出口	中等（需分配skb，有协议栈交互）	skb结构体分配，可能涉及线性区/非线性区	策略路由、带宽管理、隧道封装
Socket	Socket层（用户态与内核态边界）	低到中（取决于过滤粒度）	Socket缓冲区，可绑定到特定连接	透明加密、连接跟踪、协议过滤

性能关键点：XDP在驱动层执行，完全绕过内核协议栈，CPU开销最低。TC虽然需要skb分配，但能访问完整的协议元数据。Socket程序适合在连接粒度做策略，但会引入上下文切换开销。

eBPF Map是内核态与用户态共享数据的核心结构。不同的Map类型对内存占用和访问性能有显著差异：

哈希表（BPF_MAP_TYPE_HASH）：动态分配，适合随机查找。内存开销随条目数线性增长，且存在哈希冲突时的链式存储开销。
数组（BPF_MAP_TYPE_ARRAY）：预分配连续内存，访问速度最快（O(1)），但内存浪费在稀疏场景下明显。
LRU哈希表（BPF_MAP_TYPE_LRU_HASH）：带淘汰机制的哈希表，适合有上限的连接跟踪表。内存可控，但淘汰逻辑增加CPU开销。
Per-CPU数组（BPF_MAP_TYPE_PERCPU_ARRAY）：每个CPU核心一份独立副本，消除锁竞争，但内存占用放大N倍（N=CPU核数）。

  资源画像建议：在Cilium中，连接跟踪表（CT Map）通常使用LRU哈希表，而策略规则表（Policy Map）使用Per-CPU数组以提升并发性能。内存规划时需考虑Per-CPU放大因子。

eBPF验证器在程序加载时执行静态分析，确保程序不会导致内核崩溃或死循环。验证过程本身消耗CPU资源：

注意：验证器只在程序加载时运行一次，不影响运行时性能。但频繁加载（如策略变更时）会消耗大量CPU，需在优化中考虑加载频率与验证时间的平衡。

JIT（Just-In-Time）编译器将eBPF字节码转换为本地机器指令，是运行时性能的关键：

编译模式	CPU开销	内存开销	执行效率
解释执行	低（无编译）	低（仅字节码）	低（每条指令需解码）
JIT编译	中（编译时）	中（机器码+字节码）	高（直接执行）
JIT+优化	高（编译时优化）	高（优化后机器码）	极高（寄存器分配、指令重排）

JIT编译后的机器码直接缓存在内核内存中，不会被换出。对于Cilium这类频繁调用的数据面程序，JIT带来的性能提升远大于编译时的CPU开销。

验证器和JIT编译在程序生命周期中扮演不同角色，但共同影响CPU和内存：

加载阶段：验证器消耗CPU（路径枚举），JIT编译器消耗CPU（指令翻译）和内存（机器码缓存）。
运行阶段：验证器不再参与，JIT编译后的机器码直接执行，CPU效率最高。
内存持久性：JIT编译后的机器码驻留在内核内存中，直到程序卸载。对于Cilium，核心程序（如bpf_lxc.o）的机器码大小通常在10KB~50KB之间。

  优化策略：在资源受限环境中，可考虑预编译（提前JIT）或使用内核模块预加载，避免运行时验证和编译的CPU峰值。Cilium的bpf_compile工具支持离线编译。

在进行Cilium数据面资源画像时，需重点关注以下eBPF相关指标：

实践建议：在Cilium部署前，使用bpftool prog list和bpftool map list查看当前加载的程序和Map内存占用。结合perf stat统计eBPF程序执行次数和CPU周期，建立基线资源画像。