On Mon, Oct 12, 2026 at 11:40:02PM +0800, Leon Hwang wrote: > Similar to the tracing_multi link support for kernel functions [1], add > support for bpf progs. > > With this support, I'll be able to enhance the function-graph feature of > bpfsnoop [2]. It will trace all bpf progs, including their subprogs, to > draw a full function call graph including bpf prog call sites. > > The attachment could speed-up when there are hundreds of targets. For > example, on high CPU core count servers, it probably runs 200 tc-bpf > progs as Kubernetes CNI, and each tc-bpf prog might have 4 subprogs. > Hence, there will be 1000 targets to trace for bpfsnoop's function-graph > feature. > > With tracing_multi link support for bpf progs, bpfsnoop will be able to > attach to all targets quickly. > > When attaching to 1000 targets, fentry.multi is much faster than fentry > on a 16c16g QEMU VM on an AMD EPYC 9745 server. > > ./bench tracing-multi-attach-progs > Setting up benchmark 'tracing-multi-attach-progs'... > tracing-multi-attach-progs: prepared 1000 identical BPF program targets > tracing-multi-attach-progs: fentry created and attached 1000 programs/links > in 338.171ms > tracing-multi-attach-progs: fentry.multi created one program and attached one > 1000-target link in 47.345ms > tracing-multi-attach-progs: fentry.multi creation/attachment speedup is 7.14x
it's faster, but the original attachment is under 1s, so not really a problem imo I guess the api is better for your use case, like having less file descriptors open ? jirka
