On 15/10/26 05:59, Jiri Olsa wrote: > 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 ?
Correct. The original attachment is fast enough. So there is no need to improve attachment performance with a large patch series. Even though the series brings two benefits: * One bpf link for multiple bpf prog targets. * Support for all archs that have trampoline support. But, I also doubt the value of this series. Thanks, Leon
