From: Anton Protopopov <aspsk@isovalent.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Charalampos Stylianopoulos <charalampos.stylianopoulos@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Nick Zavaritsky <mejedi@gmail.com>,
aspsk2@gmail.com
Subject: Re: [PATCH bpf-next 0/4] expose number of map entries to userspace
Date: Tue, 7 Jan 2025 07:48:28 +0000 [thread overview]
Message-ID: <Z3zcTB+SjPK5QOt9@eis> (raw)
In-Reply-To: <28acb589-6632-4250-a8ca-00eacda03305@iogearbox.net>
On 25/01/06 05:19PM, Daniel Borkmann wrote:
> On 1/6/25 3:53 PM, Charalampos Stylianopoulos wrote:
> > This patch series provides an easy way for userspace applications to
> > query the number of entries currently present in a map.
> >
> > Currently, the number of entries in a map is accessible only from kernel space
> > and eBPF programs. A userspace program that wants to track map utilization has to
> > create and attach an eBPF program solely for that purpose.
> >
> > This series makes the number of entries in a map easily accessible, by extending the
> > main bpf syscall with a new command. The command supports only maps that already
> > track utilization, namely hash maps, LPM maps and queue/stack maps.
>
> An earlier attempt to directly expose it to user space can be found here [0], which
> eventually led to [1] to only expose it via kfunc for BPF programs in order to avoid
> extending UAPI.
>
> Perhaps instead add a small libbpf helper (e.g. bpf_map__current_entries to complement
> bpf_map__max_entries) which does all the work to extract that info via [1] underneath?
One small thingy here is that bpf_map_sum_elem_count() is only
available from the map iterator. Which means that to get the
bpf_map_sum_elem_count() for one map only, one have to iterate
through the whole set of maps (and filter out all but one).
I wanted to follow up my series by either adding the result of
calling bpf_map_sum_elem_count() to map_info as u32 or to add
possibility to provide a map_fd/map_id when creating an iterator
(so that it is only called for one map). But so far I haven't
a real use case for getting the number of elements for one map only.
> Thanks,
> Daniel
>
> [0] https://lore.kernel.org/bpf/20230531110511.64612-1-aspsk@isovalent.com/
> [1] https://lore.kernel.org/bpf/20230705160139.19967-1-aspsk@isovalent.com/
> https://lore.kernel.org/bpf/20230719092952.41202-1-aspsk@isovalent.com/
>
> > Charalampos Stylianopoulos (4):
> > bpf: Add map_num_entries map op
> > bpf: Add bpf command to get number of map entries
> > libbpf: Add support for MAP_GET_NUM_ENTRIES command
> > selftests/bpf: Add tests for bpf_map_get_num_entries
> >
> > include/linux/bpf.h | 3 ++
> > include/linux/bpf_local_storage.h | 1 +
> > include/uapi/linux/bpf.h | 17 +++++++++
> > kernel/bpf/devmap.c | 14 ++++++++
> > kernel/bpf/hashtab.c | 10 ++++++
> > kernel/bpf/lpm_trie.c | 8 +++++
> > kernel/bpf/queue_stack_maps.c | 11 +++++-
> > kernel/bpf/syscall.c | 32 +++++++++++++++++
> > tools/include/uapi/linux/bpf.h | 17 +++++++++
> > tools/lib/bpf/bpf.c | 16 +++++++++
> > tools/lib/bpf/bpf.h | 2 ++
> > tools/lib/bpf/libbpf.map | 1 +
> > .../bpf/map_tests/lpm_trie_map_basic_ops.c | 5 +++
> > tools/testing/selftests/bpf/test_maps.c | 35 +++++++++++++++++++
> > 14 files changed, 171 insertions(+), 1 deletion(-)
> >
>
next prev parent reply other threads:[~2025-01-07 7:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 14:53 [PATCH bpf-next 0/4] expose number of map entries to userspace Charalampos Stylianopoulos
2025-01-06 14:53 ` [PATCH bpf-next 1/4] bpf: Add map_num_entries map op Charalampos Stylianopoulos
2025-01-06 14:53 ` [PATCH bpf-next 2/4] bpf: Add bpf command to get number of map entries Charalampos Stylianopoulos
2025-01-07 17:52 ` kernel test robot
2025-01-06 14:53 ` [PATCH bpf-next 3/4] libbpf: Add support for MAP_GET_NUM_ENTRIES command Charalampos Stylianopoulos
2025-01-06 14:53 ` [PATCH bpf-next 4/4] selftests/bpf: Add tests for bpf_map_get_num_entries Charalampos Stylianopoulos
2025-01-06 16:19 ` [PATCH bpf-next 0/4] expose number of map entries to userspace Daniel Borkmann
2025-01-07 7:43 ` Anton Protopopov
2025-01-07 7:48 ` Anton Protopopov [this message]
[not found] ` <CAAvdH+yNG=GefEd5CcP_52gPzzZexWMMxFAxnM3isX04iErMfQ@mail.gmail.com>
2025-01-07 11:10 ` Charalampos Stylianopoulos
2025-01-09 17:37 ` Anton Protopopov
2025-01-14 11:38 ` Nick Zavaritsky
2025-01-16 14:59 ` Anton Protopopov
2025-01-16 17:52 ` Nick Zavaritsky
2025-01-17 10:35 ` Anton Protopopov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z3zcTB+SjPK5QOt9@eis \
--to=aspsk@isovalent.com \
--cc=aspsk2@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=charalampos.stylianopoulos@gmail.com \
--cc=daniel@iogearbox.net \
--cc=mejedi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.