On Fri, Jun 23, 2023 at 12:51:21PM +0200, Daniel Borkmann wrote:
> On 6/22/23 11:53 AM, Anton Protopopov wrote:
> > Add a generic percpu stats for bpf_map elements insertions/deletions in order
> > to keep track of both, the current (approximate) number of elements in a map
> > and per-cpu statistics on update/delete operations.
> >
> > To expose these stats a particular map implementation should initialize the
> > counter and adjust it as needed using the 'bpf_map_*_elements_counter' helpers
> > provided by this commit. The counter can be read by an iterator program.
> >
> > A bpf_map_sum_elements_counter kfunc was added to simplify getting the sum of
> > the per-cpu values. If a map doesn't implement the counter, then it will always
> > return 0.
> >
> > Signed-off-by: Anton Protopopov <aspsk@xxxxxxxxxxxxx>
> > ---
> > include/linux/bpf.h | 30 +++++++++++++++++++++++++++
> > kernel/bpf/map_iter.c | 48 ++++++++++++++++++++++++++++++++++++++++++-
> > 2 files changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index f58895830ada..20292a096188 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -275,6 +275,7 @@ struct bpf_map {
> > } owner;
> > bool bypass_spec_v1;
> > bool frozen; /* write-once; write-protected by freeze_mutex */
> > + s64 __percpu *elements_count;
>
> To avoid corruption on 32 bit archs, should we convert this into local64_t here?
Looks like using this_cpu_inc we can do it lockless on archs which support it
(AFAICS this is x86_64, arm64, s390, and loongarch). Otherwise we can use
atomic64_t (local64_t will switch to atomic64_t in any case for such systems).
