On 10/26/21 8:30 PM, Andrii Nakryiko wrote:
On 10/22/21 3:02 PM, Joanne Koong wrote:
This patch adds the libbpf infrastructure for supporting a
per-map-type "map_extra" field, whose definition will be
idiosyncratic depending on map type.
For example, for the bloom filter map, the lower 4 bits of
map_extra is used to denote the number of hash functions.
Please note that until libbpf 1.0 is here, the
"bpf_create_map_params" struct is used as a temporary
means for propagating the map_extra field to the kernel.
Signed-off-by: Joanne Koong <joannekoong@xxxxxx>
---
include/uapi/linux/bpf.h | 1 +
tools/include/uapi/linux/bpf.h | 1 +
tools/lib/bpf/bpf.c | 27 ++++++++++++++++++++-
tools/lib/bpf/bpf_gen_internal.h | 2 +-
tools/lib/bpf/gen_loader.c | 3 ++-
tools/lib/bpf/libbpf.c | 41 ++++++++++++++++++++++++++++----
tools/lib/bpf/libbpf.h | 3 +++
tools/lib/bpf/libbpf.map | 2 ++
tools/lib/bpf/libbpf_internal.h | 25 ++++++++++++++++++-
9 files changed, 96 insertions(+), 9 deletions(-)
[...]
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index db6e48014839..751cfb9778dc 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -400,6 +400,7 @@ struct bpf_map {
char *pin_path;
bool pinned;
bool reused;
+ __u64 map_extra;
};
enum extern_type {
@@ -2313,6 +2314,17 @@ int parse_btf_map_def(const char *map_name,
struct btf *btf,
}
map_def->pinning = val;
map_def->parts |= MAP_DEF_PINNING;
+ } else if (strcmp(name, "map_extra") == 0) {
+ /*
+ * TODO: When the BTF array supports __u64s, read into
+ * map_def->map_extra directly.
+ */
Please drop the TODO comment. There are no plans to extend BTF arrays
to support __u64 sizes.
I see, I will remove this.
If BTF arrays never support __u64 sizes, then people won't be able to
define a map in libbpf
that uses bits 33 - 64 of the map_extra field, correct? Or is there a
workaround for them that
I'm not seeing?
[...]
