On 10/9/20 11:04 PM, Alexei Starovoitov wrote:
On Fri, Oct 09, 2020 at 10:42:42PM +0200, Daniel Borkmann wrote:
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index b97bc5abb3b8..593963e40956 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -435,6 +435,11 @@ enum {
/* Share perf_event among processes */
BPF_F_PRESERVE_ELEMS = (1U << 11),
+
+/* Do not inline (array) map lookups so the array map can be used for
+ * map in map with dynamic max entries.
+ */
+ BPF_F_NO_INLINE = (1U << 12),
};
I'm worried about this one.
It exposes internal detail into uapi.
Most users are not even aware of that map_lookup_elem() can be 'inlined'.
How about renaming the flag into BPF_F_INNER_MAP ?
This way if we change the implementation later it will still be sane from uapi pov.
The comment above the flag can say:
/* Create a map that is suitable to be an inner map with dynamic max entries */
Or some other name ?
May be tomorrow we decide to simply load max_entries value in array_map_gen_lookup().
The progs will become a bit slower, but it could be fine if we also do another
optimization at the same time. Like the verifier can detect that 'key' is const
and optimize it even further. Than slower gen_lookup for inner and all arrays
will be mitigated by ultra fast lookup when !F_INNER_MAP and key is const.
For F_INNER_MAP and key is const we could still do better inlining.
Hm, yes, agree. BPF_F_INNER_MAP is more generic and doesn't tell anything about
implementation, and ultimately it's only about using it as inner array. I'll take
it and do a v4.
Thanks,
Daniel
