xdp example new BPF_MAP_TYPE_LPM_TRIE map requires BPF_F_NO_PREALLOC

[vincentmli]

Hi,

I have been playing with examples/xdp to add new map like below

diff --git a/examples/xdp/xdp.c b/examples/xdp/xdp.c
index 15424dc..b3c8e4e 100644
--- a/examples/xdp/xdp.c
+++ b/examples/xdp/xdp.c
@@ -7,6 +7,15 @@ char __license[] SEC("license") = "Dual MIT/GPL";
 
 #define MAX_MAP_ENTRIES 16
 
+enum {
+       BPF_F_NO_PREALLOC = (1U << 0),
+};
+
+struct ip4_trie_key {
+       __u32 prefixlen;
+       __u8 addr[4];
+};
+
 /* Define an LRU hash map for storing packet count by source IPv4 address */
 struct {
        __uint(type, BPF_MAP_TYPE_LRU_HASH);
@@ -15,6 +24,14 @@ struct {
        __type(value, __u32); // packet count
 } xdp_stats_map SEC(".maps");
 
+struct {
+       __uint(type, BPF_MAP_TYPE_LPM_TRIE);
+       __uint(max_entries, MAX_MAP_ENTRIES);
+       __type(key, struct ip4_trie_key);
+       __type(value, __u32);
+       __uint(map_flags, BPF_F_NO_PREALLOC);
+} xdp_dvbs_map SEC(".maps");
+

without __uint(map_flags, BPF_F_NO_PREALLOC);, I ran into issue with

cilium/ebpf/examples/xdp# CGO_ENABLED=0 go build .
cilium/ebpf/examples/xdp# ./xdp lo
2023/02/23 13:33:12 loading objects: field XdpDvbsMap: map xdp_dvbs_map: map create: invalid argument (without BTF k/v)

if I add __uint(map_flags, BPF_F_NO_PREALLOC);, but then I need to add the enum for BPF_F_NO_PREALLOC like above. I am wondering if there are any good advices for me to add the BPF_MAP_TYPE_LPM_TRIE map properly

[vincentmli]

I realized ebpf-go will create BPF_MAP_TYPE_LPM_TRIE map with BPF_F_NO_PREALLOC, I need to make sure the bpf c code map also has the BPF_F_NO_PREALLOC.

[ti-mo]

Hey @vincentmli!

I realized ebpf-go will create BPF_MAP_TYPE_LPM_TRIE map with BPF_F_NO_PREALLOC,

What do you mean by this? The caller is definitely responsible for setting NO_PREALLOC on LPM maps, the code you found was likely from the feature probes. As far as I can see, the flag is not automatically applied to maps read from ELFs, and I think we should keep it that way.

[vincentmli]

ah, I jump to conclusion too quickly. yes you are right the code I found in this library is for feature probing. the reason I come across this flag is when I modified the XDP sample program from this library to use BPF_MAP_TYPE_LPM_TRIE map, the error is cryptic to me as new user of this library to write program from scratch and google search did not help much. then I found XDP sample program from dropbox goebpf library, I create same BPF_MAP_TYPE_LPM_TRIE map and it just works, in this specific example, goebpf library is easier for beginners, but there isn't much activity in goebpf and not much update for other new features, just my observation from a new library user point of view when come across this specific example :)

[ti-mo]

I don't think that's entirely fair criticism. We go out of our way to make errors as informative as we can and do all of the heavy lifting for the user. The kernel is rather limited in what it can provide as feedback during syscall input validation. EINVAL is all you get, and that's not a limitation of the library. This user experience will be the same across all Go/Rust/C libs.

As a tip: look into the kernel's selftests, it's full of (mostly valid) examples that can be used in your programs. As always, feel free to reach out here or on Slack in #ebpf-go if you get stuck, no matter how insignificant it feels! It'll help us document and improve.

[vincentmli]

oh sorry no, it is not criticism, sorry if my word made you feel that way. I think it is mainly my lack of experience with ebpf when writing program from scratch.

[ti-mo]

It's all good, not personally offended (it's just code 😉). Just trying to set your expectations by making clear that we're already doing a lot to reduce the pain, and some speed bumps are to be expected when starting out.

Again, definitely don't hesitate to reach out on Slack for these kinds of questions!