Andrii Nakryiko <andrii.nakry...@gmail.com> writes:
> On Tue, Oct 1, 2019 at 12:18 PM John Fastabend <john.fastab...@gmail.com>
> wrote:
>>
>> Toke Høiland-Jørgensen wrote:
>> >
>> > > +struct bpf_map_def {
>> > > + unsigned int type;
>> > > + unsigned int key_size;
>> > > + unsigned int value_size;
>> > > + unsigned int max_entries;
>> > > + unsigned int map_flags;
>> > > + unsigned int inner_map_idx;
>> > > + unsigned int numa_node;
>> > > +};
>> >
>> > Didn't we agree on no new bpf_map_def ABI in libbpf, and that all
>> > additions should be BTF-based?
>> >
>> > -Toke
>> >
>>
>> We use libbpf on pre BTF kernels so in this case I think it makes
>> sense to add these fields. Having inner_map_idx there should allow
>> us to remove some other things we have sitting around.
>
> We had a discussion about supporting non-BTF and non-standard BPF map
> definition before and it's still on my TODO list to go and do a proof
> of concept how that can look like and what libbpf changes we need to
> make. Right now libbpf doesn't support those new fields anyway, so we
> shouldn't add them to public API.
This was the thread; the context was libbpf support in iproute2:
https://lore.kernel.org/netdev/20190820114706.18546-1-t...@redhat.com/
Basically, we agreed that rather than adding more fields to bpf_map_def
in libbpf itself, we'd support BTF definitions natively, and provide
applications the right callbacks to support custom formats as they see
fit.
-Toke
