Re: Access to a BPF map from a module

[Anton Ivanov <anton.ivanov@kot-begemot.co.uk>]

On 07/07/2021 16:21, Daniel Borkmann wrote:
> 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?

IIRC, I tried to use that, but ran into another not exported symbol.

In any case, I want to load the switchdev "code" as well as any supporting infra via bpftool and pin it.

The actual module is given paths to the code and maps via sysfs. This allows changing the bpf code on the fly as well as using different versions of the bpf code on a per switch interface basis.


>
>>> 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.

It is somewhat similar.

The difference is that in order to implement a working "switch" for the switchdev, you end up with multiple instances of the same program having to use common data structures as an IPC. That means loading maps, pinning them and using the pinned maps for the different instances.

>
>>> alternative to your proprietary module.
>> I intend to upstream it. In fact the WIP is already on github.
>
> Thanks,
> Daniel
>
-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/