最近在使用 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 配置变更的

drgn 是 Linux 系统可编程的调试器，基于 Python 脚本简单、便利地读取内核数据结构和变量。 理所当然地，drgn 可以用来学习 bpf，用来 inspect bpf map、bpf pro

eBPF Talk: 跟踪 IRQ 绑核 eBPF Talk: 跟踪 RPS/XPS 配置变更 eBPF Talk: 跟踪 ipv4 sysctl 配置变更 既然实现了 eBPF Talk: 跟踪 IRQ 绑核，那么也实现一下跟踪 RPS/XPS 配置变更吧。 RPS/XPS 是什么？RPS 是 Receive Packet Stee