如何解决 eBPF sockmap 重定向转发中背压缺失带来的 OOM ？

[SunBK201]

我在尝试使用 eBPF 的 BPF_PROG_TYPE_SK_SKB 与 BPF_MAP_TYPE_SOCKHASH 实现 socket 的铰接转发，目标是基于 bpf_sk_redirect_hash 将一个 socket 的 ingress 队列数据转发到另一个 socket 的 egress 队列，但是在实际的吞吐量测试时出现了系统 OOM 。

具体的环境如下：

1. Linux Kernel 6.8
2. 2 个 socket 所处网络接口不同，且 2 个网络接口带宽不一致，转发源 socket 所处接口 (测试用的 loopback) 带宽高于目标 socket 所处带宽
3. 吞吐测试是在 loopback 上使用 netperf 建立源 socket 连接，目标是转发到另一个网络接口的 socket egress 发送队列进行发送
4. 具体代码可以见 https://github.com/SunBK201/UA3F/blob/v3.3.0/src/internal/bpf/sockmap/sockmap.c

我的疑问：

1. 是否是因为由于网络接口带宽不一致（源网络接口产生的流量远大于目标网络接口所能承载发送的网络带宽），再加上 bpf_sk_redirect_hash 没有背压（流量控制），导致数据堆积造成 OOM ?
2. 如果是因为背压缺失的原因，该如果解决？实现流控 or 这种场景用 eBPF 做不合适？

希望各位前辈大佬指教！

[swananan]

我不太熟悉这个，插个眼，等大哥回复。

我本来是想 ebpf redirect 是 unix domain socket 场景的优化方案，我看到你出现了 oom 有点震惊，不是有 sk send_buf 之类可以背压保护吗。问了 ai ，说 ebpf redirect 这个实现，直接绕开了这个限制。。。

我又问了 ai ，说 绕开的原因是什么，ai 说，是因为 ebpf redirect 运行在软中断里面，没有进程上下文可以阻塞，我觉得这个很合理，说服了我。

那既然这样，就不适合用 ebpf redirect 方案，去解决这种生产者消费者速率不匹配的场景问题了。

ai 推荐了 splice 和 io-uring 。

以上是我边搬砖（围观 cc ）边水贴问的，耗时不过十几分钟，按我以前的经验，要探索到这个阶段，得花一个晚上。。。

[SunBK201]

@swananan 感谢回复。其实我之前就是用 splice 做的，用 eBPF 就是想看看能不能再把转发性能提升一些，目前测试看来对于发送时延和 CPU 负载都能有 20% 到 30% 的优化提升，不过目前看来可能只适用于网络接口带宽收发对等的场景。

[openstackceph]

可以分析一下 kmalloc-2048 分配使用情况

[macscsbf]

没看懂需求是什么还有怎么测试，我可以那我机子测试下。