Re: bpf_map_create usage question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux