On Tue, Mar 15, 2022 at 12:46 PM Grant Seltzer Richman <grantseltzer@xxxxxxxxx> wrote: > > On Tue, Mar 15, 2022 at 2:50 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Tue, Mar 15, 2022 at 1:22 AM Grant Seltzer Richman > > <grantseltzer@xxxxxxxxx> wrote: > > > > > > Hi there, > > > > > > If I call `bpf_map_create()` successfully I'll have a file descriptor > > > and not a `struct bpf_map`. This stifles me from using a lot of the > > > `bpf_map__` API functions, for example `bpf_map__pin()`. What's the > > > reason for this? Is there a way to get a `struct bpf_map` that I'm > > > missing? > > > > > > > bpf_map_create() is a low-level libbpf API. It does create a map and > > returns FD. But it is not "integrated" with struct bpf_map APIs, which > > are so-called high-level libbpf APIs. bpf_object/bpf_map/bpf_program > > and related APIs are high-level APIs and they expect ELF BPF object > > file to declaratively define everything. You can use low-level APIs by > > getting FDs from high-level bpf_map/bpf_program using bpf_map__fd() > > and bpf_program__fd(), but constructing bpf_map from FD isn't easy or > > straightforward and should be avoided, if possible. > > Thank you for the explanation! > > > > > But one way to do this is to still declaratively define map in BPF > > object file, but then do bpf_map__reuse_fd() to substitute already > > created map by FD. This way libbpf won't create another map, it will > > just use your FD. But definitions of maps have to be compatible in > > terms of key/value sizes, max_entries, etc. In short: it's painful. > > > > > > As a bit of aside, I do think we are missing high-level APIs to work > > with bpf_map elements, something like bpf_map__lookup_elem() and > > bpf_map__update_elem() has been on my mind for a while, but I haven't > > gotten time to get to it. It would further minimize the need to drop > > down to low-level APIs. > > Would these just call into bpf_map_update_elem() and > bpf_map_lookup_elem()? They'd take a *bpf_map and pass the member fd > to the low level functions? Yes, but I'd model API to accept explicit key/value sizes and validate them internally based on bpf_map's definition. It's a pretty common mistake (especially with per-CPU maps) to pass insufficient buffers to write/read data to/from. Requiring users to explicitly specify the size seems like a good idea. > > > > > > > > Thanks so much, > > > Grant Seltzer > > > > > > P.s. been a while since I've worked on adding docs, but I will finally > > > be getting back to it! > > > > Great, looking forward!