* Access to a BPF map from a module @ 2021-07-05 15:59 Anton Ivanov 2021-07-07 0:53 ` Alexei Starovoitov 0 siblings, 1 reply; 6+ messages in thread From: Anton Ivanov @ 2021-07-05 15:59 UTC (permalink / raw) To: bpf 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? -- Anton R. Ivanov https://www.kot-begemot.co.uk/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Access to a BPF map from a module 2021-07-05 15:59 Access to a BPF map from a module Anton Ivanov @ 2021-07-07 0:53 ` Alexei Starovoitov 2021-07-07 7:09 ` Anton Ivanov 0 siblings, 1 reply; 6+ messages in thread From: Alexei Starovoitov @ 2021-07-07 0:53 UTC (permalink / raw) To: Anton Ivanov; +Cc: bpf 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. 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 alternative to your proprietary module. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Access to a BPF map from a module 2021-07-07 0:53 ` Alexei Starovoitov @ 2021-07-07 7:09 ` Anton Ivanov 2021-07-07 15:21 ` Daniel Borkmann 0 siblings, 1 reply; 6+ messages in thread From: Anton Ivanov @ 2021-07-07 7:09 UTC (permalink / raw) To: Alexei Starovoitov; +Cc: bpf 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. 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. > 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. > alternative to your proprietary module. I intend to upstream it. In fact the WIP is already on github. > -- Anton R. Ivanov https://www.kot-begemot.co.uk/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Access to a BPF map from a module 2021-07-07 7:09 ` Anton Ivanov @ 2021-07-07 15:21 ` Daniel Borkmann 2021-07-07 15:31 ` Anton Ivanov 0 siblings, 1 reply; 6+ messages in thread From: Daniel Borkmann @ 2021-07-07 15:21 UTC (permalink / raw) To: Anton Ivanov, Alexei Starovoitov; +Cc: bpf 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Access to a BPF map from a module 2021-07-07 15:21 ` Daniel Borkmann @ 2021-07-07 15:31 ` Anton Ivanov 2021-07-07 15:37 ` Anton Ivanov 0 siblings, 1 reply; 6+ messages in thread From: Anton Ivanov @ 2021-07-07 15:31 UTC (permalink / raw) To: Daniel Borkmann, Alexei Starovoitov; +Cc: bpf 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Access to a BPF map from a module 2021-07-07 15:31 ` Anton Ivanov @ 2021-07-07 15:37 ` Anton Ivanov 0 siblings, 0 replies; 6+ messages in thread From: Anton Ivanov @ 2021-07-07 15:37 UTC (permalink / raw) To: Daniel Borkmann, Alexei Starovoitov; +Cc: bpf On 07/07/2021 16:31, Anton Ivanov wrote: > > 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. Sorry, pressed send by mistake. Forgot to add - the biggest hurdle in implementing a switchdev is that switchdev has to handle its notifications generated by bridge and the routing stack. As there is no BPF support for handling notification chains and adding that is non-trivial, I need to handle them in a module in C and write them out to a map. That is the actual use case - the module handles the notification and writes to the map. That also has to be a module. It does not belong in the kernel proper. A. > > >> >>>> 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-07 15:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-05 15:59 Access to a BPF map from a module Anton Ivanov 2021-07-07 0:53 ` Alexei Starovoitov 2021-07-07 7:09 ` Anton Ivanov 2021-07-07 15:21 ` Daniel Borkmann 2021-07-07 15:31 ` Anton Ivanov 2021-07-07 15:37 ` Anton Ivanov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).