[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d71dc18f397becb9e7120a0f3253828d045e1ae0.camel@gmail.com>
Date: Tue, 05 Aug 2025 10:14:23 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>, Ilya Leoshkevich
<iii@...ux.ibm.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
<daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Ian Rogers
<irogers@...gle.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, bpf
<bpf@...r.kernel.org>, "linux-perf-use."
<linux-perf-users@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
linux-s390 <linux-s390@...r.kernel.org>, Thomas Richter
<tmricht@...ux.ibm.com>, Jiri Olsa <jolsa@...nel.org>, Heiko Carstens
<hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Alexander Gordeev
<agordeev@...ux.ibm.com>
Subject: Re: [PATCH v3 1/2] libbpf: Add the ability to suppress perf event
enablement
On Tue, 2025-08-05 at 09:45 -0700, Alexei Starovoitov wrote:
> On Tue, Aug 5, 2025 at 6:04 AM Ilya Leoshkevich <iii@...ux.ibm.com> wrote:
> >
> > Automatically enabling a perf event after attaching a BPF prog to it is
> > not always desirable.
> >
> > Add a new no_ioctl_enable field to struct bpf_perf_event_opts. While
> > introducing ioctl_enable instead would be nicer in that it would avoid
> > a double negation in the implementation, it would make
> > DECLARE_LIBBPF_OPTS() less efficient.
> >
> > Suggested-by: Jiri Olsa <jolsa@...nel.org>
> > Co-developed-by: Thomas Richter <tmricht@...ux.ibm.com>
> > Signed-off-by: Thomas Richter <tmricht@...ux.ibm.com>
> > Signed-off-by: Ilya Leoshkevich <iii@...ux.ibm.com>
> > ---
Acked-by: Eduard Zingerman <eddyz87@...il.com>
[...]
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -499,9 +499,11 @@ struct bpf_perf_event_opts {
> > __u64 bpf_cookie;
> > /* don't use BPF link when attach BPF program */
> > bool force_ioctl_attach;
> > + /* don't automatically enable the event */
> > + bool no_ioctl_enable;
>
> The patch logic looks fine, but I feel the knob name is too
> implementation oriented.
> imo "dont_auto_enable" is more descriptive and easier
> to reason about.
>
> Let's wait for Eduard/Andrii reviews. This patch has to go
> via bpf trees first while the latter via perf.
Agree with Alexei,
something like "dont_enable" should be simpler to read.
Powered by blists - more mailing lists