[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <81BFF6AD-A8B7-4D15-AB31-2DEEE904B881@fb.com>
Date: Tue, 29 Sep 2020 21:08:39 +0000
From: Song Liu <songliubraving@...com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
CC: Daniel Borkmann <daniel@...earbox.net>,
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 Sep 29, 2020, at 12:28 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> 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.
BPF_F_PRESERVE_ELEMS sounds best to me. I will go ahead with it.
Thanks,
Song
Powered by blists - more mailing lists