Re: [PATCH bpf-next v3 2/4] bpf, libbpf: Support global percpu data

[Leon Hwang <leon.hwang@linux.dev>]

On 3/6/25 07:50, Andrii Nakryiko wrote:
> On Wed, May 28, 2025 at 7:44 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>>
>>
>> On 29/5/25 00:05, Andrii Nakryiko wrote:
>>> On Tue, May 27, 2025 at 7:35 PM Alexei Starovoitov
>>> <alexei.starovoitov@gmail.com> wrote:
>>>>
>>
>> [...]
>>
>>>>
>>>> I guess this can be a follow up.
>>>> With extra flag lookup/update/delete can look into a new field
>>>> in that anonymous struct:
>>>>         struct { /* anonymous struct used by BPF_MAP_*_ELEM and
>>>> BPF_MAP_FREEZE commands */
>>>>                 __u32           map_fd;
>>>>                 __aligned_u64   key;
>>>>                 union {
>>>>                         __aligned_u64 value;
>>>>                         __aligned_u64 next_key;
>>>>                 };
>>>>                 __u64           flags;
>>>>         };
>>>>
>>>
>>> Yep, we'd have two flags: one for "apply across all CPUs", and another
>>> meaning "apply for specified CPU" + new CPU number field. Or the same
>>> flag with a special CPU number value (0xffffffff?).
>>>
>>>> There is also "batch" version of lookup/update/delete.
>>>> They probably will need to be extended as well for consistency ?
>>>> So I'd only go with the "use data to update all CPUs" flag for now.
>>>
>>> Agreed. But also looking at generic_map_update_batch() it seems like
>>> it just routes everything through single-element updates, so it
>>> shouldn't be hard to add batch support for all this either.
>>
>> Regarding BPF_MAP_UPDATE_{ELEM,BATCH} support for percpu_array maps —
>> would it make sense to split the flags field as [cpu | flags]?
> 
> We coul;d encode CPU number as part of flags, but I'm not sure what we
> are trying to achieve here. Adding a dedicated field for cpu number
> would be in line of what we did for BPF_PROG_TEST_RUN, so I don't see
> a big problem.
> 

It's to avoid breaking existing APIs, such as libbpf's
bpf_map_update_elem() and bpf_map__update_elem(). Otherwise, we would
need to introduce new percpu-specific versions, like
bpf_map_update_percpu_elem() and bpf_map__update_percpu_elem().

Thanks,
Leon