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

[Andrii Nakryiko]

On Mon, Aug 24, 2026 at 10:15 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
>
> On 25/8/26 04:02, Andrii Nakryiko wrote:
> > On Sun, Aug 23, 2026 at 10:00 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> >>
> >> On 22/8/26 01:46, Andrii Nakryiko wrote:
> >>> On Sun, Aug 16, 2026 at 11:20 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> >>>>
> >>>> On 15/8/26 04:14, Andrii Nakryiko wrote:
> >>>>> On Sun, Aug 9, 2026 at 8:01 AM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> >>>>>>
> >>>>>> 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

that's mostly a convenience which is pretty trivial to abstract away
in user space, not really a hard requirement for kernel to support
this

> 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.
>

sure, post a new version, but it's a bit less motivating to add extra
complexity to the kernel if the only outcome is slight speed up and
user space convenience of having single FD

let's look at new revision and see how this goes

> Thanks,
> Leon
>