Re: Access to a BPF map from a module

[Daniel Borkmann <daniel@iogearbox.net>]

On 7/7/21 9:09 AM, Anton Ivanov wrote:
> On 07/07/2021 01:53, Alexei Starovoitov wrote:
>> On Mon, Jul 5, 2021 at 9:00 AM Anton Ivanov
>> <anton.ivanov@kot-begemot.co.uk> wrote:
>>> Hi List,
>>>
>>> I have the following problem.
>>>
>>> I want to perform some operations on a bpf map from a loadable module. The map is instantiated elsewhere and pinned.
>>>
>>> How do I go about to obtain the map inside the module?
>>>
>>> bpf_map_get* functions are not exported at present so they are not available. Is there another way besides them to fetch a bpf map "by fs name" in a kernel module?
>>>
>>> If the access limitation is intentional, may I ask what is the actual rationale behind this decision?
>> BPF objects (like maps) and BPF infra are not extensible or accessible
>> from modules.
> 
> Programs are.
> 
> You can grab a program using bpf_prog_get_type_path and use it. It is an exported symbol.

Right, sadly for the netfilter xt_bpf hack as the only user. :/ The typical way to
retrieve would be to get the program via bpf_prog_get_type() from modules.

> The only thing missing is an equivalent of bpf_prog_get_type_path for maps, let's say bpf_map_get_path
> 
> In fact, I already have a patch for that too. I wanted to understand the rationale behind the restriction before submitting it.

There is a bpf_map_get(), out of curiosity, why do you need a path variant specifically?

>> That is intentional to make sure that BPF development stays on the public
>> mailing list and within the kernel.
>> If you could describe your use case we hopefully will be able to come
>> up with upstreamable
> 
> Build a switchdev switch to be used in conjunction with the normal kernel bridge/routing infra which uses BPF "firmware"
> 
> Rationale:
> 
> 1. So people can play with switchdev and smartnics in general without having esoteric hardware
> 
> 2. So people can play with these both on the kernel side and on the "guts/internals" side.

Wouldn't it be enough to load the BPF "firmware" for that switchdev in kernel via regular
prog fd, meaning similar to what we do with tc BPF case today? From a higher level it
sounds like the same use case as tc BPF just that its 'internal' to the switchdev.

>> alternative to your proprietary module.
> I intend to upstream it. In fact the WIP is already on github.

Thanks,
Daniel