Re: [PATCH bpf-next 00/13] bpf: Add tracing_multi link support for bpf progs

On 25/8/26 04:02, Andrii Nakryiko wrote:

On Sun, Aug 23, 2026 at 10:00 PM Leon Hwang [off-list ref] wrote:

quoted

On 22/8/26 01:46, Andrii Nakryiko wrote:

quoted

On Sun, Aug 16, 2026 at 11:20 PM Leon Hwang [off-list ref] wrote:

quoted

On 15/8/26 04:14, Andrii Nakryiko wrote:

quoted

On Sun, Aug 9, 2026 at 8:01 AM Leon Hwang [off-list ref] wrote:

quoted

Similar to the tracing_multi link support for kernel functions [1], add
support for bpf progs.

When attaching to bpf progs, it must attaches to the target by text poke
way.

Please spend a bit more human effort on justification for the change
and explaining your use case. In what case you'll be attaching to a
large amount of BPF programs such that attachment speed-up (if there
is any) matters.

Will update the cover letter with justification and my use case.

Here's my use case:

I'm planning to enhance the function-graph feature of bpfsnoop [1]. It
will trace all bpf progs, including their subprogs, to draw a full
function call graph including bpf prog call sites.

fair enough, interesting use case, definitely outline that in the next
revision (and provide before/after attach time as well for such use
case, please)

Will include my use case.

Implemented the attachment micro-benchmark. Here's the result on an
x86_64 16c16g VM:

./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 679.324ms
tracing-multi-attach-progs: fentry.multi created one program and
attached one 1000-target link in 470.042ms
tracing-multi-attach-progs: fentry.multi creation/attachment speedup is
1.45x

The speedup 1.45x looks good. But attaching to 1000 progs via fentry

I'd say "meh". If 500ms is ok, 700ms is not that much more noticeable.

Besides the attachment speedup, this series provides a way to attach to
multiple bpf progs via one link. The current revision reuses the
ftrace-based attachment, which relies on
CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS. In the next revision, it will get
rid of CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS with its own attachment
implementation. Hence, this series will be able to run on those arches
that have trampoline support.

Thanks,
Leon