From: Anton Protopopov <aspsk@isovalent.com>
To: Hou Tao <houtao@huaweicloud.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH v4 bpf-next 5/6] selftests/bpf: test map percpu stats
Date: Thu, 6 Jul 2023 11:54:04 +0000 [thread overview]
Message-ID: <ZKarXOLIEWxxsQvJ@zh-lab-node-5> (raw)
In-Reply-To: <5efebb7d-138a-5353-2bc2-a2a1ffa66a2d@huaweicloud.com>
On Thu, Jul 06, 2023 at 06:49:02PM +0800, Hou Tao wrote:
> Hi,
>
> On 7/6/2023 12:01 AM, Anton Protopopov wrote:
> > Add a new map test, map_percpu_stats.c, which is checking the correctness of
> > map's percpu elements counters. For supported maps the test upserts a number
> > of elements, checks the correctness of the counters, then deletes all the
> > elements and checks again that the counters sum drops down to zero.
> >
> > The following map types are tested:
> >
> > * BPF_MAP_TYPE_HASH, BPF_F_NO_PREALLOC
> > * BPF_MAP_TYPE_PERCPU_HASH, BPF_F_NO_PREALLOC
> > * BPF_MAP_TYPE_HASH,
> > * BPF_MAP_TYPE_PERCPU_HASH,
> > * BPF_MAP_TYPE_LRU_HASH
> > * BPF_MAP_TYPE_LRU_PERCPU_HASH
> > * BPF_MAP_TYPE_LRU_HASH, BPF_F_NO_COMMON_LRU
> > * BPF_MAP_TYPE_LRU_PERCPU_HASH, BPF_F_NO_COMMON_LRU
> > * BPF_MAP_TYPE_HASH_OF_MAPS
> >
> > Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
>
> Acked-by: Hou Tao <houtao1@huawei.com>
>
> With two nits below.
Thanks, fixed both for v5.
> > +
> > +static const char *map_type_to_s(__u32 type)
> > +{
> > + switch (type) {
> > + case BPF_MAP_TYPE_HASH:
> > + return "HASH";
> > + case BPF_MAP_TYPE_PERCPU_HASH:
> > + return "PERCPU_HASH";
> > + case BPF_MAP_TYPE_LRU_HASH:
> > + return "LRU_HASH";
> > + case BPF_MAP_TYPE_LRU_PERCPU_HASH:
> > + return "LRU_PERCPU_HASH";
> > + default:
> > + return "<define-me>";
> > + }
> Missing BPF_MAP_TYPE_HASH_OF_MAPS ?
> > +}
> > +
> > +static __u32 map_count_elements(__u32 type, int map_fd)
> > +{
> > + __u32 key = -1;
> > + int n = 0;
> > +
> > + while (!bpf_map_get_next_key(map_fd, &key, &key))
> > + n++;
> > + return n;
> > +}
> > +
> > +#define BATCH true
> > +
> > +static void delete_and_lookup_batch(int map_fd, void *keys, __u32 count)
> > +{
> > + static __u8 values[(8 << 10) * MAX_ENTRIES];
> > + void *in_batch = NULL, *out_batch;
> > + __u32 save_count = count;
> > + int ret;
> > +
> > + ret = bpf_map_lookup_and_delete_batch(map_fd,
> > + &in_batch, &out_batch,
> > + keys, values, &count,
> > + NULL);
> > +
> > + /*
> > + * Despite what uapi header says, lookup_and_delete_batch will return
> > + * -ENOENT in case we successfully have deleted all elements, so check
> > + * this separately
> > + */
>
> It seems it is a bug in __htab_map_lookup_and_delete_batch(). I could
> post a patch to fix it if you don't plan to do that by yourself.
This should be as simple as
@@ -1876,7 +1876,8 @@ __htab_map_lookup_and_delete_batch(struct bpf_map *map,
total += bucket_cnt;
batch++;
if (batch >= htab->n_buckets) {
- ret = -ENOENT;
+ if (!total)
+ ret = -ENOENT;
goto after_loop;
}
goto again;
However, this might be already utilized by some apps to check that they've read
all entries. Two local examples are map_tests/map_in_map_batch_ops.c and
map_tests/htab_map_batch_ops.c. Another example I know is from BCC tools:
https://github.com/iovisor/bcc/blob/master/libbpf-tools/map_helpers.c#L58
Can we update comments in include/uapi/linux/bpf.h?
> > + CHECK(ret < 0 && (errno != ENOENT || !count), "bpf_map_lookup_and_delete_batch",
> > + "error: %s\n", strerror(errno));
> > +
> > + CHECK(count != save_count,
> > + "bpf_map_lookup_and_delete_batch",
> > + "deleted not all elements: removed=%u expected=%u\n",
> > + count, save_count);
> > +}
> > +
> SNIP
> > +static __u32 get_cur_elements(int map_id)
> > +{
> > + LIBBPF_OPTS(bpf_iter_attach_opts, opts);
> > + union bpf_iter_link_info linfo;
> > + struct map_percpu_stats *skel;
> > + struct bpf_link *link;
> > + __u32 n_elements;
> > + int iter_fd;
> > + int ret;
> > +
> > + opts.link_info = &linfo;
> > + opts.link_info_len = sizeof(linfo);
> > +
> > + skel = map_percpu_stats__open();
> > + CHECK(skel == NULL, "map_percpu_stats__open", "error: %s", strerror(errno));
> > +
> > + skel->bss->target_id = map_id;
> > +
> > + ret = map_percpu_stats__load(skel);
> > + CHECK(ret != 0, "map_percpu_stats__load", "error: %s", strerror(errno));
> > +
> > + link = bpf_program__attach_iter(skel->progs.dump_bpf_map, &opts);
>
> Instead of passing a uninitialized opts, I think using NULL will be fine
> here because there is no option for bpf map iterator now.
>
next prev parent reply other threads:[~2023-07-06 11:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 16:01 [PATCH v4 bpf-next 0/6] bpf: add percpu stats for bpf_map Anton Protopopov
2023-07-05 16:01 ` [PATCH v4 bpf-next 1/6] bpf: add percpu stats for bpf_map elements insertions/deletions Anton Protopopov
2023-07-05 16:01 ` [PATCH v4 bpf-next 2/6] bpf: add a new kfunc to return current bpf_map elements count Anton Protopopov
2023-07-05 16:01 ` [PATCH v4 bpf-next 3/6] bpf: populate the per-cpu insertions/deletions counters for hashmaps Anton Protopopov
2023-07-06 1:24 ` Alexei Starovoitov
2023-07-06 5:47 ` Anton Protopopov
2023-07-05 16:01 ` [PATCH v4 bpf-next 4/6] bpf: make preloaded map iterators to display map elements count Anton Protopopov
2023-07-05 16:01 ` [PATCH v4 bpf-next 5/6] selftests/bpf: test map percpu stats Anton Protopopov
2023-07-06 10:49 ` Hou Tao
2023-07-06 11:54 ` Anton Protopopov [this message]
2023-07-06 12:21 ` Hou Tao
2023-07-06 12:57 ` Anton Protopopov
2023-07-07 1:41 ` Hou Tao
2023-07-07 7:28 ` Anton Protopopov
2023-07-07 9:40 ` Hou Tao
2023-07-07 11:06 ` Anton Protopopov
2023-07-05 16:01 ` [PATCH v4 bpf-next 6/6] selftests/bpf: check that ->elem_count is non-zero for the hash map Anton Protopopov
2023-07-06 1:26 ` Alexei Starovoitov
2023-07-06 5:44 ` Anton Protopopov
2023-07-06 17:03 ` Alexei Starovoitov
2023-07-06 17:43 ` Anton Protopopov
2023-07-06 17:48 ` Alexei Starovoitov
2023-07-06 18:35 ` Anton Protopopov
2023-07-06 20:33 ` Alexei Starovoitov
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=ZKarXOLIEWxxsQvJ@zh-lab-node-5 \
--to=aspsk@isovalent.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=houtao@huaweicloud.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox