On Tue, Sep 21, 2021 at 7:02 PM Joanne Koong <joannekoong@xxxxxx> wrote:
>
>
> On 9/21/21 2:02 PM, Joanne Koong wrote:
> > This patch adds the libbpf infrastructure that will allow the user to
> > specify a configurable number of hash functions to use for the bloom
> > filter map.
> >
> > Please note that this patch does not enforce that a pinned bloom filter
> > map may only be reused if the number of hash functions is the same. If
> > they are not the same, the number of hash functions used will be the one
> > that was set for the pinned map.
> >
> > Signed-off-by: Joanne Koong <joannekoong@xxxxxx>
> > ---
> > include/uapi/linux/bpf.h | 5 ++++-
> > tools/include/uapi/linux/bpf.h | 5 ++++-
> > tools/lib/bpf/bpf.c | 2 ++
> > tools/lib/bpf/bpf.h | 1 +
> > tools/lib/bpf/libbpf.c | 32 +++++++++++++++++++++++++++-----
> > tools/lib/bpf/libbpf.h | 2 ++
> > tools/lib/bpf/libbpf.map | 1 +
> > tools/lib/bpf/libbpf_internal.h | 4 +++-
> > 8 files changed, 44 insertions(+), 8 deletions(-)
> >
[...]
> >
> > struct btf_map_def {
> > @@ -201,6 +202,7 @@ struct btf_map_def {
> > __u32 map_flags;
> > __u32 numa_node;
> > __u32 pinning;
> > + __u32 nr_hash_funcs;
> > };
> >
>
> I just realized that Andrii's comment on v1 stated that btf_map_def is
> fixed indefinitely.
>
> This implies that for bloom filter maps where the number of hash
> functions needs to be set,
> we will not be able to use the BTF-defined format and will instead need
> to use the older
> map definition that uses bpf_map_def. Is my understanding of this
> correct? If so, I will go
> ahead and fix this for v4.
You are confusing bpf_map_def (which is part of the public libbpf API,
even if to-be-deprecated) and btf_map_def, which is only
libbpf-internal. So it's ok to modify that struct.
>
> > int parse_btf_map_def(const char *map_name, struct btf *btf,
