On Thu Oct 15, 2026 at 1:48 AM UTC, Leon Hwang wrote: > 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.
I'm not sure about the value as well. You also need to benchmark detach time. Overall the perf improvement is too minor vs added complexity, but the first couple patches in the set look like a nice cleanup. Pls resend them. pw-bot: cr
