On Thu, Jul 17, 2025 at 12:38 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote: > > This patch adds libbpf support for the BPF_F_CPU flag in percpu_array maps, > introducing the following APIs: > > 1. bpf_map_update_elem_opts(): update with struct bpf_map_update_elem_opts > 2. bpf_map_lookup_elem_opts(): lookup with struct bpf_map_lookup_elem_opts > 3. bpf_map__update_elem_opts(): high-level wrapper with input validation > 4. bpf_map__lookup_elem_opts(): high-level wrapper with input validation > > Behavior: > > * If opts->cpu == (u32)~0, the update is applied to all CPUs. > * Otherwise, it applies only to the specified CPU. > * Lookup APIs retrieve values from the target CPU when BPF_F_CPU is used. > > Signed-off-by: Leon Hwang <leon.hwang@xxxxxxxxx> > --- please use "libbpf: " prefix, not "bpf,libbpf:" Then see my comment on flags vs separate field for cpu passing. If we go with just using flags, then I'd probably drop all the new libbpf APIs, because we already have bpf_map_lookup_elem_flags() and bpf_map_update_elem() (the latter accepts flags), so as far as low-level API we are good. The comment describing the new BPF_F_CPU flag is good, so let's add it, but place it into bpf_map__lookup_elem() description (which, btw, also accepts flags, so no changes to API itself is necessary). Same for bpf_map__update_elem(). validate_map_op() logic will stay, but just will extract cpu from flags, right? So overall less API churn, but same possibilities for users (plus we get better documentation, which is always nice). > tools/lib/bpf/bpf.c | 23 ++++++++++++++ > tools/lib/bpf/bpf.h | 36 +++++++++++++++++++++- > tools/lib/bpf/libbpf.c | 56 +++++++++++++++++++++++++++++++---- > tools/lib/bpf/libbpf.h | 53 ++++++++++++++++++++++++++++----- > tools/lib/bpf/libbpf.map | 5 ++++ > tools/lib/bpf/libbpf_common.h | 14 +++++++++ > 6 files changed, 173 insertions(+), 14 deletions(-) > [...]