eBPF struct_ops 可编程网络数据平面与 SmartNIC 硬件卸载工程实践

在云原生与 AI 计算融合的时代，数据中心网络正经历从"固定功能交换"到"软件定义可编程"的深刻转变。eBPF struct_ops 机制让我们能够在不重新编译内核的前提下，动态替换内核网络协议栈的核心数据结构操作——本文将从机制原理出发，深入探讨如何基于 struct_ops 构建可编程网络数据平面，并结合 SmartNIC 硬件卸载实现百万级连接、微秒级延迟的生产级部署。

---

一、为什么需要可编程数据平面

传统内核协议栈的设计目标是"通用性"而非"极致性能"。在 AI 训练集群中，AllReduce 通信的 RoCEv2 流量对 PFC（Priority Flow Control）和 ECN 标记的响应延迟要求在微秒级；在微服务网格中，Sidecar 代理带来的 CPU 开销已占到应用容器的 30%。

核心矛盾在于：内核协议栈为兼容性保留了过多的中间抽象层，而硬件卸载（SmartNIC/DPU）又要求控制平面能够快速迭代。我们需要一种机制，既能保持内核态的执行效率，又能动态修改关键网络路径——这正是 eBPF struct_ops 的用武之地。

1.1 传统 trap 方案的瓶颈

早期 eBPF 网络方案（XDP、tc）工作在数据平面入口，擅长包过滤和转发，但无法修改 TCP/IP 协议栈内部的拥塞控制、缓冲区管理、连接调度等核心逻辑。Kprobe/tracepoint 虽然能 hook 函数入口，但存在三大缺陷：

• 性能损耗：每个被 hook 的函数都需要 save/restore 寄存器上下文
• 稳定性风险：内核函数签名变化时 probe 点失效，难以跨内核版本维护
• 功能受限：只能观察和修改参数，无法替换整个操作集合

1.2 struct_ops 的本质突破

struct_ops 首次出现在 Linux 5.17（2022年），并在 Linux 6.x 中逐步成熟。它的核心思想是：将内核核心数据结构中的函数指针集合（即 struct ops）替换为用户态可控制的 BPF 程序。

// 内核定义的拥塞控制操作集合
struct tcp_congestion_ops {
    /* 拥塞窗口初始化 */
    void (*init)(struct sock *sk);
    /* 拥塞窗口撤销 */
    void (*release)(struct sock *sk);
    /* ACK 处理 */
    void (*cong_avoid)(struct sock *sk, u32 ack, u32 acked);
    /* 丢包事件 */
    u32  (*ssthresh)(struct sock *sk);
    /* 拥塞事件处理 */
    void (*cong_control)(struct sock *sk, const struct_rate_sample *rs);
    /* 状态管理 */
    void (*set_state)(struct_sock *sk, u8 new_state);
    /* cwnd 事件 */
    void (*cwnd_event)(struct sock *sk, enum tcp_ca_event ev);
    /* in_flight 计算 */
    u32  (*undo_cwnd)(struct sock *sk);
    /* 标志位 */
    u32 flags;
    /* 名称 */
    char name[TCP_CA_NAME_MAX];
    struct module *owner;
};

当我们将这个 ops 的函数指针全部替换为 BPF 程序的入口时，就实现了：在不加载内核模块的前提下，用用户编写的 BPF 代码完全替代 TCP 拥塞控制逻辑。

这与传统的内核模块方案相比有本质区别：内核模块直接写函数指针，缺乏边界验证；struct_ops 通过 BPF Type Format (BTF) 确保类型安全和内存安全，verifier 能够验证所有指针解引用和内存访问的合法性。

---

二、机制深度解析：struct_ops 运行时模型

2.1 BTF 驱动的运行时绑定

struct_ops 的 BPF 程序不是通过 kprobe attach 的，而是通过 BTF type ID 实现类型精确匹配。整个注册流程如下：

用户态程序
    │
    ├── 1. 加载 BPF ELF 对象
    │      └─ BPF 程序定义在 SEC(".struct_ops") section
    │
    ├── 2. 调用 BPF_MAP_TYPE_STRUCT_OPS 注册
    │      └─ libbpf 查找 __btf_map_struct_ops_tcp_congestion_ops
    │
    ├── 3. BPF 子系统验证
    │      └─ verifier 对照内核 struct tcp_congestion_ops 的 BTF
    │         逐字段确认函数签名匹配
    │
    ├── 4. 替换函数指针
    │      └─ 将 ops->init/release/cong_avoid 等指向 BPF prog
    │
    └── 5. 全局生效
           └─ 所有匹配的 sock 立即使用新 BPF 逻辑

2.2 三种 struct_ops 注册模式

Linux 内核支持三种模式的 struct_ops 注册，分别对应不同的运行时语义：

模式一：注册全局替换（Register）

// 全局注册，影响所有后续创建的 TCP 连接
__s32 bpf_tcp_cong_avoid(struct sock *sk, u32 ack, u32 acked)
{
    struct tcp_sock *tp = tcp_sk(sk);
    u32 cwnd = tp->snd_cwnd;

    // 自定义 AIMD 算法
    if (cwnd < tp->snd_ssthresh) {
        // 慢启动阶段：指数增长
        cwnd += max(acked, 1U);
    } else {
        // 拥塞避免：线性增长
        if (tp->snd_cwnd_cnt >= cwnd) {
            cwnd++;
            tp->snd_cwnd_cnt = 0;
        }
        tp->snd_cwnd_cnt += acked;
    }

    tp->snd_cwnd = min(cwnd, tp->snd_cwnd_clamp);
    return 0;
}

这种模式最简单，但影响面最大——一旦注册，所有新创建的 TCP 连接都使用新的拥塞控制算法。若 BPF 程序存在逻辑缺陷，可能导致全局性连接异常。

模式二：注册但不激活（Register + Activate）

// 此时 ops 已经注册到内核，但不会用于新连接
// 需要先显式 activate 后才会替换默认 TCP ops

struct bpf_link *link = bpf_map__attach_struct_ops(skel->maps.cong_map);
if (!link) {
    // error handling
}

// 等待确认 struct_ops 已激活
// 需要轮询 BPF_MAP_TYPE_STRUCT_OPS 的 value[0] 状态

这种模式允许我们在激活前进一步测试 BPF 程序的正确性，适合生产环境的灰度发布流程。

模式三：Per-struct 附加与分离（Attach / Detach）

// 注册临时 struct_ops，可在不需要时 detach
struct bpf_link *link = bpf_map__attach_struct_ops(skel->maps.cong_map);

// ... 使用一段时间后 ...

bpf_link__detach(link);  // 恢复为内核默认的 tcp_cong_ops
bpf_link__destroy(link);

这种模式最大的优势是可逆性——当 BPF 程序出现异常时，可以立即 detach 回滚到内核默认实现，无需重启系统或重新加载内核模块。

2.3 struct_ops 与常规 BPF 程序的关键差异

理解 struct_ops 与 kprobe/tracing 程序的差异至关重要：

维度	struct_ops	Kprobe BPF
附加时机	注册时全局生效	每次 hook 点执行时
调用语义	被调用者为 ops 函数	被调用者为 hook 函数
返回值处理	内核直接使用 BPF 返回值	通常用于观测，不修改控制流
性能特征	零 overhead（直接函数调用依赖）	每次有 register save/restore
内存访问	直接访问结构体字段（verifier 保证安全）	需要通过 bpf_probe_read 间接读
生命周期	与 BPF 程序生命周期相同	与 hook 点生命周期相同

---

三、实战：构建可编程 TCP 拥塞控制

3.1 开发环境搭建

我们推荐使用 libbpk 1.3+ 构建 struct_ops 程序。首先确保内核支持：

# 确认内核 BTF 支持
ls /sys/kernel/btf/vmlinux

# 确认 struct_ops 支持
grep CONFIG_BPF_STRUCT_OPS /boot/config-$(uname -r)
# CONFIG_BPF_STRUCT_OPS=y

# 确认 tcp_congestion_ops struct_ops 注册
cat /sys/kernel/btf/tcp_congestion_ops | bpftool btf dump -

项目结构采用典型的 BPF skeleton 模式：

tcp_bbr_bpfd/
├── Makefile
├── tcp_kern.c        # BPF 内核程序
├── tcp_user.c        # 用户态 loader
└── tcp.skel.h        # 由 bpftool gen skeleton 生成

3.2 BPF 内核程序实现 - 简易 BBR 算法

以下展示一个简化版 BBR (Bottleneck Bandwidth and RTT) 拥塞控制的 struct_ops 实现，重点展示 bandwidth probing 和 RTT filtering 的核心逻辑：

// tcp_kern.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

// BBR 状态定义
enum bbr_mode {
    BBR_STARTUP,
    BBR_DRAIN,
    BBR_PROBE_BW,
    BBR_PROBE_RTT,
};

struct bbr_context {
    enum bbr_mode mode;
    u64 min_rtt_us;          // 最小 RTT（10s 窗口）
    u64 min_rtt_stamp;       // 上次 min_rtt 更新时间戳
    u64 bw_lo;               // 带宽估计值低水位
    u64 bw_hi;               // 带宽估计值高水位
    u64 pacing_rate;         // 当前 pacing rate
    u32 cwnd_gain;           // CWND 增益
    u32 pacing_gain;         // Pacing 增益
    u8  cycle_idx;           // Probe BW 阶段的循环索引
    u8  full_bw_reached:1;   // 是否已达到最大带宽
    u8  round_start:1;       // 新一轮开始
    u32   round_count;        // 轮数计数器
    u64   next_rtt_delivered; // 下一个 RTT 的 delivered 计数
    u32   probe_rtt_done_stamp;
    u8    probe_rtt_round_done:1;
    u8    idle_restart:1;
    u8    packet_conservation:1;
    u32   prior_cwnd;
    u64   full_bw;           // 上次测量的满载带宽
};

// BPF MAP：存储每个 sock 的 BBR 上下文
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 65536);
    __type(key, u64);        // sock 指针
    __type(value, struct bbr_context);
} bbr_contexts SEC(".maps");

// BPF MAP：全局统计
struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 1);
    __type(key, u32);
    __type(value, u64);      // 总 ACK 数
} stats SEC(".maps");

#define BBR_SCALE           8
#define BBR_UNIT            (1 << BBR_SCALE)
#define BW_UNIT             (1ULL << 24)

static __always_inline u64 bbr_rate_bytes_per_sec(struct sock *sk, u64 rate, int gain)
{
    unsigned int mul, div;

    rate *= bpf_get_mtu_cache(sk);
    rate *= gain;
    rate >>= BBR_SCALE;
    rate *= USEC_PER_SEC / 1000 * 1000;

    return rate;
}

static __always_inline void bbr_min_rtt_filter(struct bbr_context *bbr, u64 rtt_us)
{
    u64 now = bpf_ktime_get_ns() / 1000;

    // 10 秒窗口更新 min_rtt
    if (rtt_us < bbr->min_rtt_us || now - bbr->min_rtt_stamp > MS2US(10000)) {
        bbr->min_rtt_us = rtt_us;
        bbr->min_rtt_stamp = now;
    }
}

// init: 连接建立时调用
SEC(".struct_ops")
void BPF_PROG(bpf_bbr_init, struct sock *sk)
{
    struct bbr_context bbr = {};
    u64 key = (u64)sk;

    // 初始化 BBR 参数
    bbr.mode = BBR_STARTUP;
    bbr.min_rtt_us = U32_MAX;
    bbr.min_rtt_stamp = 0;
    bbr.bw_lo = U32_MAX;
    bbr.bw_hi = 0;
    bbr.pacing_rate = BW_UNIT * 10 / 100;  // 初始 pacing rate
    bbr.cwnd_gain = BBR_UNIT * 2;            // 增益 2.0
    bbr.pacing_gain = BBR_UNIT * 2;          // 增益 2.0
    bbr.cycle_idx = 0;
    bbr.full_bw_reached = 0;
    bbr.round_start = 0;
    bbr.next_rtt_delivered = 0;
    bbr.probe_rtt_done_stamp = 0;
    bbr.probe_rtt_round_done = 0;
    bbr.idle_restart = 0;
    bbr.packet_conservation = 0;
    bbr.prior_cwnd = 0;
    bbr.full_bw = 0;

    bpf_map_update_elem(&bbr_contexts, &key, &bbr, BPF_ANY);
}

// cong_avoid: 收到 ACK 时调用
SEC(".struct_ops")
void BPF_PROG(bpf_bbr_cong_avoid, struct sock *sk, u32 ack, u32 acked)
{
    struct tcp_sock *tp;
    struct bbr_context *bbr;
    u64 key = (u64)sk;

    tp = (struct tcp_sock *)sk;
    bbr = bpf_map_lookup_elem(&bbr_contexts, &key);
    if (!bbr)
        return;

    // 估计 delivery rate
    u64 delivered = BPF_CORE_READ(tp, delivered);
    u64 interval_us = BPF_CORE_READ(tp, delivered_mstamp);
    u64 snd_us;

    if (bbr->round_start) {
        bbr->next_rtt_delivered = delivered;
        bbr->round_start = 0;
    }

    // 计算带宽估计
    if (interval_us > 0) {
        u64 bw = (delivered - BPF_CORE_READ(tp, tx_delivered)) * BW_UNIT / interval_us;

        // 取 bw_lo 和 bw_hi 的加权平均
        if (bw > bbr->bw_lo || bw < bbr->bw_hi) {
            bbr->bw_lo = min(bbr->bw_lo, bw);
            bbr->bw_hi = max(bbr->bw_hi, bw);
        }
    }

    // 状态机转换
    switch (bbr->mode) {
    case BBR_STARTUP:
        if (bbr->full_bw_reached) {
            bbr->mode = BBR_DRAIN;
            bbr->pacing_gain = BBR_UNIT / 2;  // 0.5x drain
            bbr->cwnd_gain = BBR_UNIT * 2;
        }
        break;

    case BBR_DRAIN:
        if (BPF_CORE_READ(tp, packets_out) <= bbr_inflight(bbr, bbr->bw_lo, BBR_UNIT))
            bbr->mode = BBR_PROBE_BW;
        break;

    case BBR_PROBE_BW:
        bbr_update_cyclephase(bbr);
        // ... 继续 bandwidth probing
        break;

    case BBR_PROBE_RTT:
        if (bpf_ktime_get_ns()/1000 - bbr->probe_rtt_done_stamp > MS2US(200))
            bbr->mode = BBR_PROBE_BW;
        break;
    }

    // 计算 pacing rate
    bbr->pacing_rate = bbr_inflight(bbr, bbr->bw_lo, bbr->pacing_gain);
    bbr_update_pacing_rate(sk, bbr);

    // 更新 CWND
    u32 cwnd = bbr_inflight(bbr, bbr->bw_lo, bbr->cwnd_gain);
    cwnd += bbr_extra_acked(bbr);
    cwnd = min(cwnd, BPF_CORE_READ(tp, snd_cwnd_clamp));
    tp->snd_cwnd = cwnd;
}

// ssthresh: 返回当前慢启动阈值
SEC(".struct_ops")
__u32 BPF_PROG(bpf_bbr_ssthresh, struct sock *sk)
{
    // BBR 不使用传统 ssthresh，返回一个极大值
    return 0xFFFFFFFFU;
}

// set_state: 状态切换通知
SEC(".struct_ops")
void BPF_PROG(bpf_bbr_set_state, struct sock *sk, u8 new_state)
{
    struct bbr_context *bbr;
    u64 key = (u64)sk;

    bbr = bpf_map_lookup_elem(&bbr_contexts, &key);
    if (!bbr)
        return;

    // LOSS 或 CWR 信号时重置 idle_restart
    if (new_state == TCP_CA_Loss || new_state == TCP_CA_CWR) {
        bbr->packet_conservation = 1;
    }
}

char _license[] SEC("license") = "GPL";

3.3 用户态 Loader 实现

// tcp_user.c
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <bpf/libbpf.h>
#include "tcp.skel.h"

static volatile bool exiting = false;

static void sig_handler(int sig)
{
    exiting = true;
}

int main(int argc, char **argv)
{
    struct tcp_bbr_bpf *skel;
    struct bpf_link *link;
    int err;

    /* 设置 signal handler */
    signal(SIGINT, sig_handler);
    signal(SIGTERM, sig_handler);

    /* 打开并加载 BPF skeleton */
    skel = tcp_bbr_bpf__open();
    if (!skel) {
        fprintf(stderr, "Failed to open BPF skeleton\n");
        return 1;
    }

    /* 可选：在加载前修改 BPF map 参数 */
    skel->rodata->initial_pacing_rate = 10000000;  // 10MB/s 初始

    err = tcp_bbr_bpf__load(skel);
    if (err) {
        fprintf(stderr, "Failed to load BPF skeleton: %d\n", err);
        goto cleanup;
    }

    /* 使用 struct_ops 特有的 attach API */
    link = bpf_map__attach_struct_ops(skel->maps.bbr_cong_ops);
    if (!link) {
        fprintf(stderr, "Failed to attach struct_ops: %s\n", strerror(errno));
        err = -1;
        goto cleanup;
    }

    printf("eBPF BBR congestion control registered successfully!\n");

    /* 轮询等待退出 */
    while (!exiting) {
        sleep(1);

        /* 可以输出实时统计信息 */
        __u32 key = 0;
        __u64 total_acked;
        if (bpf_map__lookup_elem(skel->maps.stats, &key, sizeof(key),
                                  &total_acked, sizeof(total_acked), 0) == 0) {
            printf("Total ACKed bytes: %llu\n", total_acked);
        }
    }

    /* 清理：detach struct_ops（恢复至内核默认） */
    bpf_link__detach(link);
    bpf_link__destroy(link);

cleanup:
    tcp_bbr_bpf__destroy(skel);
    return err != 0;
}

编译命令：

# 编译 BPF 程序
clang -O2 -g -target bpf -D__TARGET_ARCH_x86_64 \
    -I/usr/include/x86_64-linux-gnu \
    -c tcp_kern.c -o tcp_kern.o

# 生成 skeleton 头文件
bpftool gen skeleton tcp_kern.o > tcp.skel.h

# 编译用户态程序
gcc -O2 -g tcp_user.c -o tcp_bbr_user \
    -lbpf -lelf -lz

---

四、SmartNIC 硬件卸载：eBPF 的下一战场

4.1 为什么需要硬件卸载

纯软件 eBPF 虽然性能优秀，但在以下场景存在性能瓶颈：

• 小包处理：64B 包在 100Gbps 线上达到 148Mpps，CPU 每个包只有 ~6ns 处理窗口
• 状态跟踪：数百万并发连接的状态哈希表遍历消耗大量 CPU cache
• 时钟精度：ns 级 scheduling precision 受 CPU 调度 jitter 影响

SmartConnect（NVIDIA ConnectX-7/BlueField-3）支持将部分 eBPF 指令集卸载到网卡硬件执行，实现线速处理。

4.2 网络路径硬件卸载分类

应用态数据
    │
    ├── DPDK/VPP 用户态 TCP/IP 栈 ← eBPF 无法介入（用户态）
    │
    ├── 内核协议栈路径
    │   ├── XDP (eBPF) → NIC RX ring  → 硬件卸载支持
    │   ├── TC   (eBPF) → Linux TC      → 部分卸载
    │   ├── Socket-layer (struct_ops)    → 纯软件
    │   └── IP routing / netfilter        → 纯软件
    │
    └── SmartNIC 硬件卸载选项
        ├── XDP 硬件卸载 (netdev native XDP)
        ├── eBPF offload (subset of eBPF 指令)
        ├── Flow steering (eSwitch 硬件转流)
        ├── Crypto offload (TLS/IPsec)
        └── RegEx/String match offload (App Recognition)

4.3 eBPF → 硬件卸载的关键技术约束

并非所有 eBPF 程序都能卸载到 SmartNIC，需要满足严格的约束：

指令集约束：

SmartNIC 的 eBPF 加速器通常支持以下指令子集：

// 允许的指令类型
BPF_LD | BPF_W | BPF_ABS       // packet 半字节读取 (head)
BPF_LDX | BPF_W | BPF_MEM       // scratch register load/store
BPF_ALU | BPF_ADD | BPF_K       // 立即数加法
BPF_ALU | BPF_SUB | BPF_K       // 立即数减法
BPF_ALU | BPF_AND | BPF_K       // 立即数与
BPF_ALU | BPF_OR | BPF_K        // 立即数或
BPF_JMP | BPF_JEQ | BPF_K       // 条件跳转（立即数比较）
BPF_JMP | BPF_JGT | BPF_K       // 大于比较
BPF_JMP | BPF_JSET | BPF_K      // 位测试跳转
BPF_STX | BPF_W | BPF_MEM       // store to scratch

// 不支持的指令类型
BPF_CALL                        // 不允许函数调用（除有限内联）
BPF_LD | BPF_DW | BPF_IMM     // 64位立即数
BPF_JMP | BPF_JA               // 不允许绝对跳转
BPF_ALU64 | BPF_MOD | BPF_K  // 不允许模运算
BPF_ALU | BPF_DIV | BPF_K     // 不允许除法

内存访问约束：

// 允许：直接 packet 数据访问
struct xdp_md *ctx = (struct xdp_md *)cfg;
void *data_end = (void *)(long)ctx->data_end;
void *data = (void *)(long)ctx->data;

eth = data;
if ((void *)(eth + 1) > data_end)
    return XDP_PASS;

// 不允许：map 访问（硬件无法访问 host memory）
// struct value *v = bpf_map_lookup_elem(&map, &key);  // ❌ 硬件中禁止

// 允许：使用 per-CPU array（部分实现支持）

4.4 基于 struct_ops 的连接级硬件卸载设计

struct_ops 无法直接卸载到网卡硬件，但可以与 eSwitch 流表配合实现软硬件协同方案：

static int bpf_switchdev_link_switch_update(struct bpf_switchdev *sw)
{
    // 配置 eSwitch 流表，将高带宽流重定向到物理端口
    // 而 struct_ops 仍然在软件侧处理连接级 CC 状态

    struct bpf_switchdev_encap_key key = {
        .smac = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55},
        .dmac = {0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb},
        .vlan_id = 100,
    };
    struct bpf_switchdev_encap_val val = {
        .egress_port = 2,            // 物理 PF virtio 端口
        . BPF_txq_mapping = 4,       // 绑定到 4 队列
        .rate_limit_bps = 10000000000, // 10Gbps 限速
    };

    return bpf_map_update_elem(&encap_map, &key, &val, BPF_ANY);
}

编排模式：

[ 应用 ] ← 使用 struct_ops 自定义 TCP CC
    │
[ 内核 TCP 栈 ] ← BPF 程序修改 cwnd / pacing rate
    │
[ XDP/eBPF ] ← 在驱动层标记 QOS / 分流
    │
[ SmartNIC eSwitch ] ← 硬件流表重定向 / 限速
    │
[ 物理网络 ]    ← 数据包传输

4.5 生产实践：PFC 风暴的 eBPF 可控缓解

RoCEv2 网络中的 PFC（基于优先级的流量控制）风暴是最常见的生产问题之一。当网络出现拥塞时，交换机会发送 PFC pause frame 到对端，使对端暂停发送指定优先级流量。若处理不当，PFC 会级联传播导致全网瘫痪。

eBPF struct_ops 可以在 inode 级别精确检测和处理 PFC 风暴：

// 在每个 ACK 处理周期内，检测 RoCEv2 PFC 事件并调整 pacing
SEC(".struct_ops")
void BPF_PROG(bpf_bbr_cong_control, struct sock *sk, const struct rate_sample *rs)
{
    struct tcp_sock *tp = (struct tcp_sock *)sk;
    struct bbr_context *bbr;
    u64 key = (u64)sk;
    s64 bw;

    bbr = bpf_map_lookup_elem(&bbr_contexts, &key);
    if (!bbr)
        return;

    // 基线速率估计
    bw = rs->delivery_rate;

    // PFC 风暴检测：如果 delivery rate 突然崩塌且 RTT 剧增
    if (bw < bbr->bw_lo / 4 && rs->rtt_us > bbr->min_rtt_us * 5) {
        // 紧急降窗至 in_flight 的 75% 防止 PFC 风暴级联
        u32 target_cwnd = BPF_CORE_READ(tp, packets_out) * 3 / 4;
        tp->snd_cwnd = max(target_cwnd, 2U);
        tp->snd_cwnd_stamp = bpf_jiffies64();

        // 触发 pacing 紧急制动
        bbr->mode = BBR_PROBE_RTT;
        bbr->probe_rtt_done_stamp = 0;

        // 向上报告告警（可选）
        bpf_perf_event_output(sk, &pfc_alerts, BPF_F_CURRENT_CPU,
                              &(struct pfc_alert) {
                                  .sk = (u64)sk,
                                  .pfc_timestamp = bpf_ktime_get_ns(),
                                  .bw_drop_ratio = bw * 100 / bbr->bw_lo,
                              }, sizeof(struct pfc_alert));
    } else {
        // 正常 BBR 更新逻辑
        bbr_update_model(bbr, rs);
    }
}

这个模式的关键价值在于：在 sysadmin 和网络工程师来不及干预之前，节点已自动抑制拥塞传播。在传统方案中，PFC 风暴需要运维人员登录交换机配置 ECN 或调整 MTU，响应时间至少以分钟计；eBPF 的响应延迟在微秒级。

---

五、性能调优与生产部署经验

5.1 BPF Map 选型对性能的影响

struct_ops BPF 程序依赖 BPF map 管理连接状态，不同 map 类型的性能差异巨大：

// LRU_HASH 推荐用于大连接数场景（支持自动淘汰）
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);     // 百万级连接支持
    __type(key, u64);                  // sock 指针
    __type(value, struct bbr_context); // BBR 状态 (48B)
} bbr_contexts SEC(".maps");

// PERCPU_ARRAY 用于 per-CPU 计数器
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 64);           // per-CPU 统计条目
    __type(key, u32);
    __type(value, u64);
} percpu_stats SEC(".maps");

// RINGBUF 用于向用户态报告异常事件
struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 1 << 24);      // 16MB 环形缓冲区
} alert_rb SEC(".maps");

关键性能原则：

• 避免在 cong_avoid ACK 路径中使用 BPF spinlock（会消耗大量 CPU 周期）
• 优先使用 per-CPU map 做统计聚合，定期 user-space 批量读取
• LRU_HASH 的默认淘汰策略在高并发下可能导致连接态 BPF 上下文丢失，需监控淘汰率

5.2 与 CPU Scheduler 的协同

struct_ops BPF 程序在执行过程中可能被中断或抢占，需要关注两个问题：

执行时间约束：

BPF verifier 限制每个程序的最大执行指令数（默认 100 万条）。虽然 struct_ops 程序不像 XDP 那样对延迟极度敏感，但 cong_avoid 在快速路径上被频繁调用，需要确保：

// 错误：循环中 BPF 调用次数可能超出限制
for (i = 0; i < 100; i++) {
    val = bpf_map_lookup_elem(&aux, &i);  // 100 次 map 查找
}

// 正确：预计算 + 查表
static const u8 cwnd_gain_table[8] = {
    [BBR_BW_INDEX_0] = 2.77 * BBR_UNIT,   // BW 阶段 0: 增益 2.77
    [BBR_BW_INDEX_1] = 1.25 * BBR_UNIT,   // BW 阶段 1: 增益 1.25
    // ... 
};
bbr->cwnd_gain = cwnd_gain_table[bbr->cycle_idx];

RCU 语义：

struct_ops 程序可能在 bh 或 process context 中被调用。访问共享数据时必须注意：

// bh 上下文（softirq）访问 tcp_sock 字段
// softirq 已持有 socket lock，不需要额外同步

// process 上下文（setsockopt 路径）访问 struct_ops BPF map
// 需要 RCU 读锁保护，但 BPF 程序内不能调用 rcu_read_lock
// 解决方案：value 中包含指针字段时，使用 bpf_rcu_read_lock()

5.3 生产环境的安全部署流程

struct_ops 注册是全局性操作，必须遵循严格的灰度流程：

#!/bin/bash
# 生产环境 struct_ops 灰度发布脚本

PHASE=${1:-canary}

case $PHASE in
    # 阶段 1: 仅在指定的 cgroup 中测试
    canary)
        echo "Phase 1: 在 canary cgroup 中测试 BPF CC"
        # 使用 cgroup_inet_create 监听器在特定 cgroup 入口 attach
        /opt/bpf/bpf_bbr_loader --cgroup /sys/fs/cgroup/canary
        ;;

    # 阶段 2: 全局注册但低优先
    shadow)
        echo "Phase 2: 全局注册但作为 shadow（不立即使用）"
        # 注册 struct_ops 但不使用 setsockopt 激活
        /opt/bpf/bpf_bbr_loader --register-only
        ;;

    # 阶段 3: 激活并全面切换
    activate)
        echo "Phase 3: 全局激活 BPF BBR"
        /opt/bpf/bpf_bbr_loader --activate
        # 监控关键指标
        watch -n1 'ss -ti | head -30'
        ;;

    # 阶段 4: 回滚
    rollback)
        echo "Phase 4: 回滚到内核默认 CC"
        /opt/bpf/bpf_bbr_loader --detach
        ;;
esac

# 健康检查函数
check_health() {
    # 检查 RTT 是否异常
    AVG_RTT=$(ss -ti | grep rtt | awk -F'rtt:' '{print $2}' | awk -F'/' '{print $1}' | head -1)
    if (( $(echo "$AVG_RTT > 500" | bc -l) )); then
        echo "WARNING: RTT $AVG_RTT ms > 500ms threshold, triggering rollback"
        $0 rollback
    fi

    # 检查 retrans 率
    RETR_RATE=$(cat /proc/net/snmp | awk '/Tcp:/ {print $12/$11*100}')
    if (( $(echo "$RETR_RATE > 5.0" | bc -l) )); then
        echo "WARNING: Retrans rate $RETR_RATE% > 5%, triggering rollback"
        $0 rollback
    fi
}

5.4 监控可观测性

BPF struct_ops 程序的内核态观测挑战在于：没有传统 kprobe 的 tracepoint，无法通过 perf_event 获取采样数据。解决方案是：

// 使用 BPF ringbuffer 异步上报事件
SEC(".struct_ops")
void BPF_PROG(bpf_bbr_cong_control, struct sock *sk, const struct rate_sample *rs)
{
    struct bbr_event *e;

    // 只在异常事件时 perf output
    if (rs->losses > 0 || rs->rtt_us > bbr->min_rtt_us * 3) {
        e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
        if (e) {
            e->timestamp = bpf_ktime_get_ns();
            e->sk = (u64)sk;
            e->cwnd = BPF_CORE_READ(tp, snd_cwnd);
            e->bw = rs->delivery_rate;
            e->rtt_us = rs->rtt_us;
            e->losses = rs->losses;
            bpf_ringbuf_submit(e, 0);
        }
    }
}

用户态消费端：

struct bpf_buffer {
    struct ring_buffer *rb;
};

static int handle_bbr_event(void *ctx, void *data, size_t data_sz)
{
    struct bbr_event *e = data;

    // 输出到 Prometheus / Grafana 监控
    fprintf(stderr, "BBR alert: sk=%p cwnd=%u bw=%llu rtt=%u\n",
            (void *)e->sk, e->cwnd, e->bw, e->rtt_us);

    // 推送至远端遥测系统
    otlp_push_metric("bbr.event", e->bw, e->rtt_us);

    return 0;
}

---

六、总结与展望

eBPF struct_ops 代表了内核可编程性的一个重要方向——从表面观测走向深层控制。在线上生产环境部署中，我们需要特别注意：

架构要点：

• 利用 struct_ops 的可逆性（detach 即回滚），实现比内核模块更安全的协议栈定制
• BPF map 的选型直接影响性能：大连接数场景首选 LRU_HASH，高吞吐统计用 PERCPU_ARRAY
• SmartNIC 硬件卸载与 struct_ops 软件控制形成互补：前者负责线速包处理，后者负责连接级状态机

未来方向：

• Linux 6.x+ 正推进更多 struct_ops 类型（不仅是 tcp_congestion_ops，还有路由表、cgroup 控制器等）
• BPF trampoline 与 struct_ops 的结合进一步降低动态替换的 overhead
• 内核态 BBRv3 的 BPF 参考实现有望在主线合并

在传统协议栈迭代周期以"年"计的大背景下，eBPF struct_ops 让我们有了"日"级迭代网络算法的能力。这正是可编程数据平面在 AI 计算时代的核心价值：让我们对内核协议栈的理解，直接转化为可编程的生产力。

---

参考资源： - 内核 bpf_struct_ops 文档 - libbpf struct_ops API 参考 - BBR: Congestion-Based Congestion Control (ACM Queue, 2016) - Linux Plumbers Conference 2023: eBPF in Production Dataplane