SRE/DevOps – HDUO Lab

排查网络加速和防御类问题时，最怕的不是程序崩溃，而是“静默降级”。近期处理了一起由 eBPF/XDP 引起的生产节点网络吞吐雪崩事故。业务团队在新扩容的 Kubernetes 节点上部署了基于 XDP 的防 DDoS 与流量可观测 Agent，结果上线后该批次节点 P99 延迟从 2ms 飙升至 200ms 以上，QPS 断崖式下跌，单机 Load Average 飙升至机器核心数的 3 倍以上。

最终结论先行：业务侧编写 XDP 挂载逻辑时，未显式强制指定 XDP_FLAGS_DRV_MODE（Native 模式）。而新批次节点为了大数据传输开启了 Jumbo Frame（MTU=9000），导致底层网卡驱动（以 i40e 为例）拒绝了 Native XDP 挂载。更致命的是，挂载库触发了静默降级，自动回退到了 XDP_GENERIC（SKB 模式）。这使得本该在网卡驱动层极速处理的报文，全部走完了昂贵的 sk_buff 内存分配流程后再执行 XDP 逻辑，彻底击穿了 ksoftirqd，引发软中断 CPU 资源耗尽。

案发现场与指标异动

接到告警介入排查时，业务正处于高峰期。通过 mpstat -P ALL 1 观察，发现几个核心的 %soft（软中断 CPU 消耗）长期顶在 100%，而 %usr 和 %sys 极低。

快速抓取 perf top 热点函数：

# perf top -a --sort comm,dso,symbol
  28.45%  [kernel]  [k] build_skb
  15.21%  [kernel]  [k] do_softirq
  12.03%  [kernel]  [k] bpf_prog_3b185187f1855c4c_xdp_drop_func
   8.42%  [kernel]  [k] __netif_receive_skb_core

看到 build_skb 高居榜首，且紧跟在 __netif_receive_skb_core 之后执行了 bpf 相关的函数，这绝对不是一个正常的 XDP 行为。XDP (eXpress Data Path) 的核心设计哲学就是在 sk_buff 分配之前，直接在网卡 RX Ring 缓冲区操作报文。如果 XDP 程序的执行路径里大量伴随 sk_buff 的分配，说明 XDP 根本没有在 Native 模式下运行。

敲入基础网络排查命令查看网卡状态：

$ ip -details link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 0c:42:a1:53:xx:xx brd ff:ff:ff:ff:ff:ff
    prog/xdp id 142 tag 3b185187f1855c4c jited xdpgeneric

注意输出中的两个致命关键点：mtu 9000 和 xdpgeneric。破案了。

愚蠢的静默降级与底层机制剖析

这是一个典型的“为了兼容性牺牲可用性”的低级陷阱。

在 eBPF/XDP 的生态中，XDP 支持三种运行模式：

Offloaded (XDP_FLAGS_HW_MODE)：直接卸载到智能网卡硬件上执行。
Native (XDP_FLAGS_DRV_MODE)：在网卡驱动层执行，位于 DMA 完成之后、sk_buff 结构体分配之前。这是生产环境的标配。
Generic (XDP_FLAGS_SKB_MODE)：在内核网络协议栈中执行，位于 sk_buff 分配之后（__netif_receive_skb_core 中）。主要是为了让不支持 Native XDP 的网卡也能强行跑通 XDP 程序。

问题出在哪里？很多开源库或研发在编写 XDP Loader 时，为了“让程序能跑起来”，挂载时如果不指定 Flag（即 flags = 0），内核和 libbpf 等库的默认行为是：先尝试 Native 模式，如果失败，静默回退（Fallback）到 Generic 模式。

为什么新节点的 Native 模式会失败？因为新节点由于某些存储业务的混部需求，将 eth0 的 MTU 改成了 9000（Jumbo Frame）。在许多主流网卡驱动（如 Intel ixgbe, i40e 在老版本内核）中，当 MTU 超过一个 Page Size（通常是 4KB），报文会跨页存储，而驱动的 XDP Native 实现由于内存布局限制，无法安全处理这种跨页报文，从而在挂载时返回 EOPNOTSUPP (Operation not supported)。

挂载程序在收到失败后，自作聪明地用 XDP_GENERIC 重新挂载成功了。结果就是：对于每一个抵达网卡的网络包，内核不仅要像往常一样消耗 CPU 周期分配 sk_buff，还要额外再跑一遍 XDP 里的 BPF 字节码。对于一个设计初衷是防 DDoS 的 XDP 程序来说，这简直是引狼入室——原本可以单核无压力扛下百万 pps 丢弃的流量，现在几万 pps 就能把机器的软中断 CPU 打满，导致正常业务报文排队直至超时，最终酿成雪崩。

防御性加固与解决方案

在基础设施的工程实践中，Fail-Fast（快速失败）永远好于静默降级。对于性能敏感型组件，宁愿程序启动报错退出，也绝不能以一种极其消耗资源的方式苟活。

1. 强制阻断 Generic 降级路径

在用户态 Loader（无论是 C/C++ 的 libbpf 还是 Go 的 cilium/ebpf）中，挂载 XDP 程序时必须显式指定 XDP_FLAGS_DRV_MODE。

如果是基于 libbpf 的 C 代码：

// 严禁使用 flags = 0;
__u32 flags = XDP_FLAGS_UPDATE_IF_NOEXIST | XDP_FLAGS_DRV_MODE;
int err = bpf_set_link_xdp_fd(ifindex, prog_fd, flags);
if (err) {
    fprintf(stderr, "FATAL: Failed to attach XDP in Native Mode. Error: %d\n", err);
    exit(EXIT_FAILURE); // 拒绝降级，直接报错中断部署
}

如果是 Go 语言使用 cilium/ebpf：

link, err := netlink.LinkByName("eth0")
// ...
err = netlink.LinkSetXdpFdWithFlags(link, prog.FD(), int(netlink.XDP_FLAGS_DRV_MODE))
if err != nil {
    log.Fatalf("Failed to attach native XDP: %v", err)
}

2. 梳理 MTU 与驱动兼容矩阵

如果业务确实依赖 Jumbo Frame，且必须使用 XDP，则需要评估底层网卡驱动及内核版本。较新的内核（例如 5.14+）和部分驱动（如 Mellanox mlx5）已经增加了对 XDP 多缓冲（multi-buffer）的支持，能够处理非线性跨页的 XDP 报文。如果硬件和内核不支持，架构上就需要将 XDP 的防御节点前置（例如部署在专属的边界清洗集群，保持 MTU 1500），而不是强行在混合了 Jumbo Frame 的 Worker 节点上跑。

XDP/eBPF 性能陷阱排查清单

为了避免类似惨剧，在涉及 eBPF/XDP 的生产环境排查时，请直接核对以下清单：

挂载模式确认 (ip link show)
- 检查输出中的标签是 xdp 还是 xdpgeneric。如果是后者，说明你的 XDP 毫无性能加速可言，反而带来了额外的 CPU 损耗。
软中断热点分析 (perf top)
- 发现 ksoftirqd CPU 偏高时，如果热点栈顶是 build_skb、__netif_receive_skb_core 伴随 bpf_prog_xxx，直接定性为 XDP 未跑在 Native 模式。
MTU 兼容性预检 (ip link show dev xxx)
- 当需要挂载 XDP 时，检查目标网卡 MTU 是否 > 1500。如果大于，查阅对应网卡驱动（ethtool -i xxx 获取驱动名）与当前内核版本对 XDP MTU 的限制要求。
XDP Map 并发瓶颈 (bpftool map show)
- 若挂载模式正确但 CPU 依旧飙高，检查 XDP 路径中是否高频使用了自旋锁（bpf_spin_lock）或存在极端大的 Hash Map 频繁查找与更新。网卡 RX 队列并发处理时，劣质的 Map 操作会引发严重的 Cache Line 颠簸。
驱动环形缓冲区积压 (ethtool -S xxx | grep rx_missed)
- 如果 XDP 程序的逻辑过于复杂（超过 BPF 指令限制或涉及深层循环），即使挂载了 Native 模式，也会导致单包处理时间变长。通过观察 rx_missed_errors 或 rx_dropped 指标，判断网卡底层缓冲区是否因消费过慢而被塞满丢包。

分类： SRE/DevOps