On 29/5/25 00:05, Andrii Nakryiko wrote:
> On Tue, May 27, 2025 at 7:35 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> 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]?
When the BPF_F_PERCPU_DATA flag is set, the value could be applied
either across all CPUs if the cpu is 0xffffffff, or to a specific CPU
otherwise.
Thanks,
Leon
