[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJKArVZBg+qLqG0=rFMHC77aOed5o+zydzuM3QXE+cZrA@mail.gmail.com>
Date: Tue, 29 Sep 2020 12:28:43 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Song Liu <songliubraving@...com>,
Network Development <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, Kernel Team <kernel-team@...com>,
Alexei Starovoitov <ast@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>
Subject: Re: [PATCH bpf-next 1/2] bpf: introduce BPF_F_SHARE_PE for perf event array
On Tue, Sep 29, 2020 at 12:18 PM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> On 9/29/20 9:00 PM, Alexei Starovoitov wrote:
> > On Tue, Sep 29, 2020 at 04:02:10PM +0200, Daniel Borkmann wrote:
> >>> +
> >>> +/* Share perf_event among processes */
> >>> + BPF_F_SHARE_PE = (1U << 11),
> >>
> >> nit but given UAPI: maybe name into something more self-descriptive
> >> like BPF_F_SHAREABLE_EVENT ?
> >
> > I'm not happy with either name.
> > It's not about sharing and not really about perf event.
> > I think the current behavior of perf_event_array is unusual and surprising.
> > Sadly we cannot fix it without breaking user space, so flag is needed.
> > How about BPF_F_STICKY_OBJECTS or BPF_F_PRESERVE_OBJECTS
> > or the same with s/OBJECTS/FILES/ ?
>
> Sounds good to me, BPF_F_PRESERVE_OBJECTS or _ENTRIES seems reasonable.
May be BPF_F_PRESERVE_ELEMENTS?
or _ELEMS ?
I think we refer to map elements more often as elements instead of entries.
But both _entries and _elems work for me.
Powered by blists - more mailing lists