在 eBPF Talk: XDP 解析所有 TCP options 里，已经做到了使用 XDP 解析所有 TCP options 的功能。 不过，其中使用了 percpu map 在 XDP 和 freplace 之间传递 offset；那么，是否有办法将该 percpu map 优化掉

在 eBPF Talk: 耗时 10 个月，修复了又一个 tailcall 的 bug 之后，再下一城，再次修复与 tailcall 有关的一个 BUG： bpf: Fix updating attached freplace prog to prog_array map BUG 危害 这个 BUG 会导致内核 panic： 1 2 3

最近在使用 ringbuf 的 bpf_ringbuf_reserve() 时踩了一个坑，记录一下。 ringbuf 简介 ringbuf 是 BPF 中能够取代 PERF_EVENT_ARRAY 的特殊 map 类型，提供了类似的 helpers: bpf_ringbuf_output(): 将数据写入 ringbuf。 bpf_ringbuf_reserve(): 为数据预留空间。 bpf_ringbuf_submit():

优化的地方如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c index 5159c7a229229..7c130001fbfe7 100644 --- a/arch/x86/net/bpf_jit_comp.c +++ b/arch/x86/net/bpf_jit_comp.c @@ -1234,13 +1234,11 @@ bool ex_handler_bpf(const struct exception_table_entry *x, struct pt_regs

使用 fentry 能解析到 TOA option，eBPF Talk: BPF 读取 TOA 的 4 种方式。 上难度，如何使用 XDP 解析所有的 TCP options 呢？ 太长不读：使用 freplace 解析 TCP option，使用 XDP 遍

在 4 层 tcp 代理的场景下，一般使用 TOA option 将真实的客户端地址和端口信息传递给后端服务。 在后端服务里，如果不使用内核模块读取 TOA，而是使用 eBPF 来读取 T

Ziv Chow 在微信群里问了个 verifier 的问题，一眼看上去肯定是 bpf 代码写得有问题，但是问题具体在哪里呢？ 数组访问 如上图，crc16tab[key] 访问 crc16tab 数组时

在 7 月 20 日早上醒来的时候，发现个好消息：修复 tailcall hierarchy 问题的 PATCH 被合并啦。 并得到 BPF 社区大佬 Alexei 的肯定： Thank you for sticking to it. Applied to bpf-next. It took almost a year, but the final fix is imo much better than all

在 Linux 内核协议栈设备层，有 2 个 tracepoint 可以用来统计网络包的延迟： net:net_dev_xmit：设备层发送 skb 的 tracepoint。 net:net

eBPF Talk: 跟踪 IRQ 绑核 eBPF Talk: 跟踪 RPS/XPS 配置变更 eBPF Talk: 跟踪 ipv4 sysctl 配置变更 实现了对 IRQ 绑核、RPS/XPS 配置变更后，接着是跟踪网卡的 net.ipv4.conf.*.* sysctl 的配置变更。 ipv4 sysctl 配置变更的