结论先行：在 XDP 网络加速场景中使用 BPF_MAP_TYPE_LRU_HASH 管理高并发会话状态时，由于内核采用了基于 Per-CPU 的伪 LRU（Pseudo-LRU）淘汰机制，在局部 Hash 冲突或跨 CPU 流量漂移时，极易触发未过期表项被强行驱逐，导致静默丢包。根本解法是：要么将 Map 容量冗余放大 3 倍以上并绑定 BPF_F_NO_COMMON_LRU，要么改用标准 BPF_MAP_TYPE_HASH 配合 RingBuffer 由用户态异步执行精确 GC。
排查过程中，我们遇到一个极其隐蔽的网络抖动问题。自研的基于 XDP（eBPF）的边缘四层负载均衡器在流量高峰期（单机 PPS 约 80万，TCP 新建连接 3万/秒），P99 延迟会偶发出现从 2ms 飙升至 1.2s 的毛刺，业务端反馈伴随少量 TCP RST。
硬件环境是 Mellanox ConnectX-6，内核版本为 5.15.0-88-generic。系统负载非常健康，Load Average 不超过单核的 50%，软中断也没有打满。常规的网络排查手段在这里全部失效：netstat -s 没看到明显丢包，nstat -az | grep drop 毫无波澜。原因很简单：XDP 挂载在网卡驱动层（Native Mode），处理时机早于 SKB 的分配，它的丢包内核网络栈根本看不见。
抓取现场：追踪被隐形的 XDP_DROP
既然内核网络栈无感，只能用 eBPF 来监控 eBPF。我们直接挂载 xdp:xdp_exception 追踪点，看看到底是不是 XDP 程序把包丢了。
# 使用 bpftrace 快速抓取 XDP_DROP 行为
bpftrace -e '
tracepoint:xdp:xdp_exception {
if (args->action == 1) { // 1 == XDP_DROP
@[args->prog_id] = count();
}
}'
输出结果清晰地指向了 ID 为 145 的 XDP 核心分发程序。通过 bpftool prog show id 145 确认，这正是处理连接追踪（Conntrack）逻辑的代码。
进一步审查逻辑：当收到一个非 SYN 的 ESTABLISHED 状态报文时，XDP 会去查询 Conntrack Map，如果查不到，直接返回 XDP_DROP（为了防御伪造的 ACK 攻击）。问题来了：明明是活跃连接，为什么在 Map 里查不到？
我们查看了这个 Map 的状态：
bpftool map show name xdp_ct_map
# 112: lru_hash name xdp_ct_map flags 0x0
# key 16B value 32B max_entries 1048576 memlock 134217728B
最大条目数是 100万（1048576），但通过脚本统计当前存量条目，仅仅只有 40 万左右。Map 远没达到容量上限，但里面活跃连接的 Key 却“凭空蒸发”了。
为什么 BPF_MAP_TYPE_LRU_HASH 会在未满容量时触发随机淘汰？
这涉及 eBPF LRU_HASH 的底层实现陷阱。很多开发认为 LRU_HASH 就是一个严格按照时间顺序淘汰最老数据的结构，但在 Linux Kernel 中，为了在极高并发下（比如几千万 PPS）避免全局自旋锁（Spinlock）的严重争抢，内核实现了一个妥协版的伪 LRU（Pseudo-LRU）。
在 kernel/bpf/bpf_lru_list.c 中，LRU Map 的内存分配和淘汰逻辑被拆分成了两级：
-
全局 LRU 链表（Global LRU List）
-
Per-CPU 局部空闲链表（Per-CPU Free List）
当一个 CPU 需要在 LRU_HASH 中插入新 Key 时：
-
优先从当前 CPU 的 Local Free List 拿内存。
-
如果 Local List 空了，它不会立刻去全局拿，而是尝试从当前 CPU 的 Local LRU 淘汰数据。
-
如果还不行，再去 Global LRU 去“偷”内存（Steal），甚至去别的 CPU 节点“偷”。
致命弱点在于 Hash 冲突与 RSS 漂移的结合：
网卡的 RSS（Receive Side Scaling）负责将流量打到不同 CPU 队列。如果短时间内某个特定的 5-Tuple（五元组）Hash 导致大量新建连接集中落在了 CPU 0，CPU 0 的 Local List 会迅速耗尽。
此时，即使全局（或者其他 CPU）还有 60 万个空闲名额，CPU 0 为了效率，也会优先执行强制淘汰。它极有可能把当前仍在活跃的连接状态踢掉。后续该连接的报文到来时（不管是落在这个 CPU 还是漂移到了别的 CPU），查询必定失败，XDP 逻辑就会无情地将包 Drop 掉。
破局之道：架构调整与代码重构
明确了由于并发不均和伪 LRU 设计导致的“抢占式淘汰”，我们有两种重构路径。
方案一：硬扛（Per-CPU 隔离 + 容量放大）
如果不改 Map 类型，必须优化内存分配行为。在创建 Map 时传入 BPF_F_NO_COMMON_LRU 标志位。
这个标志会让内核为每个 CPU 创建独立的 LRU 结构，彻底隔离全局竞争，代价是内存碎片化严重，你必须把 max_entries 设为预期的 3 倍以上。
// BPF 代码调整
struct {
__uint(type, BPF_MAP_TYPE_LRU_HASH);
__uint(max_entries, 3145728); // 放大 3 倍
__type(key, struct ct_key);
__type(value, struct ct_val);
__uint(map_flags, BPF_F_NO_COMMON_LRU); // 禁用全局 Common LRU
} xdp_ct_map SEC(".maps");
注：此方案仅适用于网卡 RSS 极为均衡，且业务五元组分布绝对均匀的场景。否则依然会有单核被打爆导致淘汰的风险。
方案二：降维打击（改用标准 HASH + RingBuffer 异步 GC）—— 我们的最终选择
放弃把复杂状态机交给内核黑盒处理。我们将 Map 类型退级为普通的 BPF_MAP_TYPE_HASH，不依赖内核的 LRU，而是由用户态 Go/Rust 程序掌控生命周期。
如何处理过期的连接？依靠 XDP 侧通过 BPF_MAP_TYPE_RINGBUF 向用户态发送 TCP FIN/RST 状态机的事件，用户态程序收到事件后，主动调用 bpf_map_delete_elem 清理。对于异常断电等没有 FIN 的死连接，用户态维持一个低频的定时器进行兜底扫盘。
// 1. 回退到基础的 BPF_MAP_TYPE_HASH
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__uint(max_entries, 1048576);
__type(key, struct ct_key);
__type(value, struct ct_val);
// HASH 必须显式预分配以保证性能
__uint(map_flags, BPF_F_NO_PREALLOC ? 0 : 0);
} xdp_ct_map SEC(".maps");
// 2. 引入 RingBuffer 传输销毁事件
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 256 * 1024); // 256KB 环形缓冲区
} ct_gc_events SEC(".maps");
// XDP 主逻辑中处理连接结束
SEC("xdp")
int xdp_lb_prog(struct xdp_md *ctx) {
// ... 报文解析逻辑 ...
if (tcp->fin || tcp->rst) {
struct gc_event *e = bpf_ringbuf_reserve(&ct_gc_events, sizeof(*e), 0);
if (e) {
e->key = ct_key;
bpf_ringbuf_submit(e, 0); // 抛给用户态 GC
}
}
// ...
}
切换到此架构后，内核不再背负沉重的 LRU 锁和节点淘汰逻辑，XDP DROP 数量彻底归零，单核软中断 CPU 消耗下降了 14%，P99 毛刺彻底消失。
常见问题 (FAQ)
Q1：如何确认服务器上的网卡 RSS 是否均衡？它对 eBPF LRU 有多大影响？
极度不均衡的 RSS 是触发 eBPF 局部 LRU 淘汰的罪魁祸首。可以通过 mpstat -P ALL 1 查看各个核的 %soft 使用率。如果只有少量核心很忙，说明 RSS 未能正确散列。检查网卡是否开启了多队列（ethtool -l eth0），并确认中断亲和性（irqbalance 或手动绑定 /proc/irq/X/smp_affinity）。
Q2：使用 BPF_MAP_TYPE_HASH 时，为什么说 BPF_F_NO_PREALLOC 对性能影响很大？
标准 Hash Map 默认是预分配内存的（Preallocated）。如果不加 BPF_F_NO_PREALLOC，内核会在加载程序时一次性吃掉所需的内存（Memlock）。但在 5.x 版本内核中，如果在高频包处理场景（如 XDP）开启了 BPF_F_NO_PREALLOC，每次 Map 更新都会触发内核 kmalloc 的内存分配机制，不仅产生巨大的自旋锁开销，还破坏了 RCU 的无锁读取优势，直接导致 PPS 吞吐腰斩。
Q3：bpftool 显示的 max_entries 是 100万，但实际只用了 40万就报错，怎么排查是 Hash 冲突还是 LRU 淘汰？
可以挂载 eBPF 探针去 trace 内核函数 bpf_lru_list_pop_free_to_local 和 htab_lru_map_update_elem 的返回值。如果看到 bpf_lru_list_pop_free_to_local 频繁触发且是从其他核 steal 内存，说明是伪 LRU 的坑。如果返回 -E2BIG 且未开启 LRU，则是纯粹的 Hash 容量满了。
Q4：为什么不直接在 eBPF 中实现一个定时器（bpf_timer）来清理连接表？
bpf_timer 是在 Linux 5.15 中引入的功能。理论上可以为每个连接起一个 timer，但对于 100 万级并发连接的四层 LB，内核中维护海量定时器的软中断开销依然非常昂贵。XDP 的设计哲学应当是 “Data plane in kernel, Control plane in user space”（数据面在内核，控制面在用户态），将海量状态的 GC 交给有庞大内存和 Go routine 调度的用户态，系统架构会更加鲁棒。