为什么冗余包的丢弃判定应该留在内核态，而不是把每次重试都升级给用户态？高负载 BPF ring buffer 又该怎样定容量、盯水位？

当 socket 层每秒收到数千次冗余的传输层重试时，第一个问题是要把“这个包是不是重复”的判定放在哪里。丢弃一个已见过的传输帧是确定性、有界状态的查找，应当留在内核态：把每一个冗余重试都升级到用户态，要在你本想过滤掉的那些包上支付上下文切换、唤醒和调度抖动——这正是过滤器本来要避开的开销。真正可行的替代方案，是一张小小的内核态去重表加一条 ring buffer 导出通路，整个设计最终归结成两个必须盯住的数字。

机制

人们最容易误判的成本是验证器。eBPF 程序在加载时被检查一次：验证器走查整个程序，证明它必然终止且只触碰边界内的内存，而这份工作是加载期一次性的复杂度预算。BPFConf 2025 关于 BPF 百万指令上限的演讲把它说清楚了：上限作用于加载期的验证器复杂度，而不是每包开销，预算被展开的循环和总是内联的 helper 消耗在膨胀的程序形状上。一个能压进该预算的程序，验证一次的成本，无论它一天跑十次还是一秒跑一千万次都一样。所以内核态去重通路的运行时成本不是程序形状，而是几次 map 操作。

这一点很关键，因为内核态唯一能跑的有界状态去重就是一张 map。一个丢弃重复帧的 socket 过滤器保留一张在途帧标识的小表，到达时做一次查找、递增一个计数、键存在就丢弃。这些操作全部在包的上下文里、在一次进程唤醒之间发生。判定保持确定性且有界，每个包的代价是常数次 map 操作。

导出通路是 ring buffer。内核的 ring buffer 实现是一个 power-of-2 的共享环形缓冲，多生产者单消费者，其数据区可被内存映射，用户态读样本时不必二次拷贝。生产者预留一块固定大小的记录；预留需要一个编译期常量大小，验证器才能证明程序不会读到记录之外。当 ring 没有剩余空间时，预留失败并返回 NULL、绝不阻塞：繁忙的生产者必须把这次未命中计下来并继续，于是 ring 满只会让可观测性降级，而不会拖住数据面。在消费者一侧，一个查询 helper 会报出未消费数据量以及当前生产、消费位置，这就是你盯背压的水位线。消费者还能选择生产者怎么唤醒它，从完全不唤醒到强制唤醒，于是繁忙的 ring 可以批量通知而不是每条记录都唤醒。每条预留记录还带一个小的头，含记录长度与一个 busy 位；在 NMI 上下文里预留即使命中也可能失败，因为它要拿一把自旋锁，而中断未必能拿到。装不进固定大小的记录，就得改用基于拷贝的 output helper，而非预留通路，因为预留只接受常量大小。

验证与调试路径

1. 在 BPF 侧数丢弃。在去重表旁放一个 per-CPU 的 dropped 计数，每次 ring buffer 预留返回 NULL 就加一。计数在涨，说明 ring 小于采样速率；计数持平而流量稳定，说明 ring 跟得上。
2. 在用户侧盯水位。报未消费数据量的那个查询 helper 同时报出生产与消费位置。两者之间的差距就是你的实时背压表：差距向 ring 容量增大，就意味着丢弃计数即将抬升。
3. 找到稳态。在满重试速率下跑，让计数沉降，读 dropped 计数与可用数据水位线。两者在流量持续时不再变化，你就找到了一个均衡的 ring 容量；若计数仍在涨，就调大 max_entries 再测。
4. 量化你正在决策的那笔权衡。在内核里丢弃的那一刻与用户态处理完的那一刻各打一个时间戳，对比两者的分布。差值就是把每次重试都升级给用户态的上下文切换与唤醒成本；正是这个数字支撑了“丢弃判定留在内核态”的决定。

局限

• 内核态去重状态受 map 的条目上限约束。满的 hash map 拒绝新插入、但更新已存在的键仍然成功，于是去重表会悄悄停止跟踪新的在途帧、同时继续丢旧帧：在归咎 ring buffer 之前，先查 map 是否已满。
• ring buffer 的丢弃是静默的，除非你去计数。ring 满时预留失败是设计行为，不是错误；没有 per-CPU 的 dropped 计数，繁忙的 ring 就只是产不出样本，而你没有任何可观测性已降级的信号。
• 预留通路需要常量记录大小。若样本是变长的，固定大小的预留装不下；改用基于拷贝的 output helper，代价是额外一次拷贝。
• 唤醒策略是你设的，不是 ring 的属性。高负载下若消费者保持默认唤醒行为，就会每条记录通知一次；用 no-wake 与 force-wake 标志批量，否则消费者把 CPU 烧在唤醒上而非样本上。

参考

• Linux 内核文档：BPF ring buffer — power-of-2 共享环形缓冲、bpf_ringbuf_reserve() 的常量大小要求及其满时不阻塞的失败、BPF_RB_AVAIL_DATA、BPF_RB_RING_SIZE、BPF_RB_CONS_POS、BPF_RB_PROD_POS 查询标志、BPF_RB_NO_WAKEUP 与 BPF_RB_FORCE_WAKEUP 唤醒控制、每记录头部、以及 NMI 上下文预留的告诫。
• libbpf ring buffer API — 用户侧的 libbpf_ring_buffer_query() 与消费者读取的 BPF_RB_AVAIL_DATA、BPF_RB_RING_SIZE、BPF_RB_CONS_POS、BPF_RB_PROD_POS 标志取值。
• BPFConf 2025：Beyond 1M BPF instructions — 把百万指令的验证器复杂度预算框定为加载期上限，消耗在展开的循环与总是内联的 helper 上。

当日社区讨论

选取的问题来自一个 opt-in 存档：一条讨论询问如何在每秒数千次并发 socket 层重试、且背后 ring buffer 负载很重的情况下，给内核态 drop 时延与用户态上下文切换成本做基准测试。该讨论是开放式的：它问的是丢弃判定留在内核态与升级到用户态的边界在哪里，以及在那种负载下如何运行并给 ring buffer 定容量，且没有附带公开一手资料或决定性边界。本页把这个边界锚定到公开的内核 ring buffer 与验证器文档：确定性的有界内核态去重判定留在内核态，ring buffer 则对着盯住的水位线加计数的丢弃来定容量。

当日其他讨论：一条 OBI 的 Kubernetes 缓存地址环境变量在 Config v2 文档下被忽略的再次提交，现附一个 helm 图拉取请求与线内确认这是真实问题、外加一个手工绕行——已发布，不重复发布。一条记录“智能体调用开始时有哪些 Agent Skills 可用”的拉取请求，使 trace 能区分“从未提供”与“提供过但输给了更弱的匹配”——也已发布。

本次运行的渠道覆盖：两个 opt-in 存档共 8 条消息，全部如上覆盖。visible-browser-only 来源（Discord、eunomia-bpf 与 sched-ext 社区、bpf 邮件列表、r/eBPF）本次未能审阅——没有可用的 visible-browser 会话——因此标记为未覆盖，而非平静。