* libbpf: pinning multiple progs from the same section @ 2021-02-07 11:35 Gilad Reti 2021-02-08 8:57 ` Gilad Reti 2021-02-08 22:36 ` Andrii Nakryiko 0 siblings, 2 replies; 15+ messages in thread From: Gilad Reti @ 2021-02-07 11:35 UTC (permalink / raw) To: bpf; +Cc: Andrii Nakryiko Hello there, Last year, libbpf added support for attaching multiple handlers to the same event by allowing defining multiple progs in the same elf section. However, the pin path for a bpf program is obtained via the __bpf_program__pin_name function, which uses an escaped version of the elf section name as the pin_name. Thus, trying to pin multiple bpf programs defined on the same section fails with "File exists" error, since libbpf tries to pin more than one program on a single path. Does adding the actual program name to the pin path makes sense? Thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-07 11:35 libbpf: pinning multiple progs from the same section Gilad Reti @ 2021-02-08 8:57 ` Gilad Reti 2021-02-08 11:42 ` Toke Høiland-Jørgensen 2021-02-08 22:36 ` Andrii Nakryiko 1 sibling, 1 reply; 15+ messages in thread From: Gilad Reti @ 2021-02-08 8:57 UTC (permalink / raw) To: bpf; +Cc: Andrii Nakryiko Also, is there a way to set the pin path to all maps/programs at once? For example, bpf_object__pin_maps pins all maps at a specific path, but as far as I was able to find there is no similar function to set the pin path for all maps only (without pinning) so that at loading time libbpf will try to reuse all maps. The only way to achieve a complete reuse of all maps that I could find is to "reverse engineer" libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and set the pin path on each map before load. On Sun, Feb 7, 2021 at 1:35 PM Gilad Reti <gilad.reti@gmail.com> wrote: > > Hello there, > > Last year, libbpf added support for attaching multiple handlers to the > same event by allowing defining multiple progs in the same elf > section. However, the pin path for a bpf program is obtained via the > __bpf_program__pin_name function, which uses an escaped version of the > elf section name as the pin_name. Thus, trying to pin multiple bpf > programs defined on the same section fails with "File exists" error, > since libbpf tries to pin more than one program on a single path. > Does adding the actual program name to the pin path makes sense? > > Thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 8:57 ` Gilad Reti @ 2021-02-08 11:42 ` Toke Høiland-Jørgensen 2021-02-08 11:57 ` Gilad Reti 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-08 11:42 UTC (permalink / raw) To: Gilad Reti, bpf; +Cc: Andrii Nakryiko Gilad Reti <gilad.reti@gmail.com> writes: > Also, is there a way to set the pin path to all maps/programs at once? > For example, bpf_object__pin_maps pins all maps at a specific path, > but as far as I was able to find there is no similar function to set > the pin path for all maps only (without pinning) so that at loading > time libbpf will try to reuse all maps. The only way to achieve a > complete reuse of all maps that I could find is to "reverse engineer" > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and > set the pin path on each map before load. You can set the 'pinning' attribute in the map definition - add '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default this will pin beneath /sys/fs/bpf, but you can customise that by setting the pin_root_path attribute in bpf_object_open_opts. -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 11:42 ` Toke Høiland-Jørgensen @ 2021-02-08 11:57 ` Gilad Reti 2021-02-08 14:28 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Gilad Reti @ 2021-02-08 11:57 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: bpf, Andrii Nakryiko On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Gilad Reti <gilad.reti@gmail.com> writes: > > > Also, is there a way to set the pin path to all maps/programs at once? > > For example, bpf_object__pin_maps pins all maps at a specific path, > > but as far as I was able to find there is no similar function to set > > the pin path for all maps only (without pinning) so that at loading > > time libbpf will try to reuse all maps. The only way to achieve a > > complete reuse of all maps that I could find is to "reverse engineer" > > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and > > set the pin path on each map before load. > > You can set the 'pinning' attribute in the map definition - add > '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default > this will pin beneath /sys/fs/bpf, but you can customise that by setting > the pin_root_path attribute in bpf_object_open_opts. Yes, I am familiar with that feature, but it has some downsides: 1. I need to set it manually on every map (and in cases that I have only the compiled object file that would be hard). 2. It only works for bpf maps and not bpf programs. 3. It only works for bpf maps that are defined explicitly in the bpf code and not for implicit (inner) bpf maps (bss, rodata, etc). > > -Toke > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 11:57 ` Gilad Reti @ 2021-02-08 14:28 ` Toke Høiland-Jørgensen 2021-02-08 14:44 ` Gilad Reti 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-08 14:28 UTC (permalink / raw) To: Gilad Reti; +Cc: bpf, Andrii Nakryiko Gilad Reti <gilad.reti@gmail.com> writes: > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> > Also, is there a way to set the pin path to all maps/programs at once? >> > For example, bpf_object__pin_maps pins all maps at a specific path, >> > but as far as I was able to find there is no similar function to set >> > the pin path for all maps only (without pinning) so that at loading >> > time libbpf will try to reuse all maps. The only way to achieve a >> > complete reuse of all maps that I could find is to "reverse engineer" >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and >> > set the pin path on each map before load. >> >> You can set the 'pinning' attribute in the map definition - add >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default >> this will pin beneath /sys/fs/bpf, but you can customise that by setting >> the pin_root_path attribute in bpf_object_open_opts. > > Yes, I am familiar with that feature, but it has some downsides: > 1. I need to set it manually on every map (and in cases that I have > only the compiled object file that would be hard). > 2. It only works for bpf maps and not bpf programs. > 3. It only works for bpf maps that are defined explicitly in the bpf > code and not for implicit (inner) bpf maps (bss, rodata, etc). Ah, right. Well, other than that I don't think there's a way to set pin paths in bulk, other than by manually iterating and setting them one at a time. But, erm, can't you just do that? :) -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 14:28 ` Toke Høiland-Jørgensen @ 2021-02-08 14:44 ` Gilad Reti 2021-02-08 15:09 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Gilad Reti @ 2021-02-08 14:44 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: bpf, Andrii Nakryiko On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Gilad Reti <gilad.reti@gmail.com> writes: > > > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> > >> Gilad Reti <gilad.reti@gmail.com> writes: > >> > >> > Also, is there a way to set the pin path to all maps/programs at once? > >> > For example, bpf_object__pin_maps pins all maps at a specific path, > >> > but as far as I was able to find there is no similar function to set > >> > the pin path for all maps only (without pinning) so that at loading > >> > time libbpf will try to reuse all maps. The only way to achieve a > >> > complete reuse of all maps that I could find is to "reverse engineer" > >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and > >> > set the pin path on each map before load. > >> > >> You can set the 'pinning' attribute in the map definition - add > >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default > >> this will pin beneath /sys/fs/bpf, but you can customise that by setting > >> the pin_root_path attribute in bpf_object_open_opts. > > > > Yes, I am familiar with that feature, but it has some downsides: > > 1. I need to set it manually on every map (and in cases that I have > > only the compiled object file that would be hard). > > 2. It only works for bpf maps and not bpf programs. > > 3. It only works for bpf maps that are defined explicitly in the bpf > > code and not for implicit (inner) bpf maps (bss, rodata, etc). > > Ah, right. Well, other than that I don't think there's a way to set pin > paths in bulk, other than by manually iterating and setting them one at > a time. But, erm, can't you just do that? :) > Sure, I can, but I think we should avoid that. As I said this forces the user to know libbpf's pin path naming algorithm, which is not part of the libbpf api afaik. I think that if we have a method to pin all maps at a specific path there should also be a method for reusing them all from this path, either by exposing the function that builds the pin path, or a function that sets all the paths from a root path. > -Toke > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 14:44 ` Gilad Reti @ 2021-02-08 15:09 ` Toke Høiland-Jørgensen 2021-02-08 15:50 ` Gilad Reti 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-08 15:09 UTC (permalink / raw) To: Gilad Reti; +Cc: bpf, Andrii Nakryiko Gilad Reti <gilad.reti@gmail.com> writes: > On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> >> >> > Also, is there a way to set the pin path to all maps/programs at once? >> >> > For example, bpf_object__pin_maps pins all maps at a specific path, >> >> > but as far as I was able to find there is no similar function to set >> >> > the pin path for all maps only (without pinning) so that at loading >> >> > time libbpf will try to reuse all maps. The only way to achieve a >> >> > complete reuse of all maps that I could find is to "reverse engineer" >> >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and >> >> > set the pin path on each map before load. >> >> >> >> You can set the 'pinning' attribute in the map definition - add >> >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default >> >> this will pin beneath /sys/fs/bpf, but you can customise that by setting >> >> the pin_root_path attribute in bpf_object_open_opts. >> > >> > Yes, I am familiar with that feature, but it has some downsides: >> > 1. I need to set it manually on every map (and in cases that I have >> > only the compiled object file that would be hard). >> > 2. It only works for bpf maps and not bpf programs. >> > 3. It only works for bpf maps that are defined explicitly in the bpf >> > code and not for implicit (inner) bpf maps (bss, rodata, etc). >> >> Ah, right. Well, other than that I don't think there's a way to set pin >> paths in bulk, other than by manually iterating and setting them one at >> a time. But, erm, can't you just do that? :) >> > > Sure, I can, but I think we should avoid that. As I said this forces > the user to know libbpf's pin path naming algorithm, which is not part > of the libbpf api afaik. Why? If you set the pin path from your application, libbpf will also try to reuse the map from that path. So you don't need to know libbpf's algorithm if you just override it with your own paths? > I think that if we have a method to pin all maps at a specific path > there should also be a method for reusing them all from this path, > either by exposing the function that builds the pin path, or a > function that sets all the paths from a root path. What you're asking for is basically a function bpf_object__set_all_pin_paths(obj, path) instead of having to do bpf_object__for_each_map(map, obj) { sprintf(path, "path/%s", bpf_map__name(map)); bpf_map__set_pin_path(map, path); } or? Is that really needed? -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 15:09 ` Toke Høiland-Jørgensen @ 2021-02-08 15:50 ` Gilad Reti 2021-02-08 17:55 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Gilad Reti @ 2021-02-08 15:50 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: bpf, Andrii Nakryiko On Mon, Feb 8, 2021 at 5:09 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Gilad Reti <gilad.reti@gmail.com> writes: > > > On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> > >> Gilad Reti <gilad.reti@gmail.com> writes: > >> > >> > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> >> > >> >> Gilad Reti <gilad.reti@gmail.com> writes: > >> >> > >> >> > Also, is there a way to set the pin path to all maps/programs at once? > >> >> > For example, bpf_object__pin_maps pins all maps at a specific path, > >> >> > but as far as I was able to find there is no similar function to set > >> >> > the pin path for all maps only (without pinning) so that at loading > >> >> > time libbpf will try to reuse all maps. The only way to achieve a > >> >> > complete reuse of all maps that I could find is to "reverse engineer" > >> >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and > >> >> > set the pin path on each map before load. > >> >> > >> >> You can set the 'pinning' attribute in the map definition - add > >> >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default > >> >> this will pin beneath /sys/fs/bpf, but you can customise that by setting > >> >> the pin_root_path attribute in bpf_object_open_opts. > >> > > >> > Yes, I am familiar with that feature, but it has some downsides: > >> > 1. I need to set it manually on every map (and in cases that I have > >> > only the compiled object file that would be hard). > >> > 2. It only works for bpf maps and not bpf programs. > >> > 3. It only works for bpf maps that are defined explicitly in the bpf > >> > code and not for implicit (inner) bpf maps (bss, rodata, etc). > >> > >> Ah, right. Well, other than that I don't think there's a way to set pin > >> paths in bulk, other than by manually iterating and setting them one at > >> a time. But, erm, can't you just do that? :) > >> > > > > Sure, I can, but I think we should avoid that. As I said this forces > > the user to know libbpf's pin path naming algorithm, which is not part > > of the libbpf api afaik. > > Why? If you set the pin path from your application, libbpf will also try > to reuse the map from that path. So you don't need to know libbpf's > algorithm if you just override it with your own paths? > If I do bpf_object__pin_maps then libbpf decides where it wants to pin them. I can set each path by my own, but then why do we need this function? All It does is pinning all the maps at paths that are not part of the api. In this libbpf version it is here, in the next it is there, and user code will need to change accordingly. For example, libbpf today uses <path>/<map_name> as the pin path, but it is also doing sanitize_pin_pathon each path. This means that after if use bpf_object__pin_maps I also need to know how libbpf sanitizes its paths and mimic that behavior on my side. > > I think that if we have a method to pin all maps at a specific path > > there should also be a method for reusing them all from this path, > > either by exposing the function that builds the pin path, or a > > function that sets all the paths from a root path. > > What you're asking for is basically a function > bpf_object__set_all_pin_paths(obj, path) > > instead of having to do > > bpf_object__for_each_map(map, obj) { > sprintf(path, "path/%s", bpf_map__name(map)); > bpf_map__set_pin_path(map, path); > } > > or? Is that really needed? > Yes, that is what I am asking for. Either that or a bpf_map__build_pin_path(path, map) That will return a pin path that is compatible with libbpf's one, and then I can iterate over all maps. > -Toke > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 15:50 ` Gilad Reti @ 2021-02-08 17:55 ` Toke Høiland-Jørgensen 2021-02-08 18:19 ` Gilad Reti 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-08 17:55 UTC (permalink / raw) To: Gilad Reti; +Cc: bpf, Andrii Nakryiko Gilad Reti <gilad.reti@gmail.com> writes: > On Mon, Feb 8, 2021 at 5:09 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> > On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> >> >> > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> >> >> >> >> > Also, is there a way to set the pin path to all maps/programs at once? >> >> >> > For example, bpf_object__pin_maps pins all maps at a specific path, >> >> >> > but as far as I was able to find there is no similar function to set >> >> >> > the pin path for all maps only (without pinning) so that at loading >> >> >> > time libbpf will try to reuse all maps. The only way to achieve a >> >> >> > complete reuse of all maps that I could find is to "reverse engineer" >> >> >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and >> >> >> > set the pin path on each map before load. >> >> >> >> >> >> You can set the 'pinning' attribute in the map definition - add >> >> >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default >> >> >> this will pin beneath /sys/fs/bpf, but you can customise that by setting >> >> >> the pin_root_path attribute in bpf_object_open_opts. >> >> > >> >> > Yes, I am familiar with that feature, but it has some downsides: >> >> > 1. I need to set it manually on every map (and in cases that I have >> >> > only the compiled object file that would be hard). >> >> > 2. It only works for bpf maps and not bpf programs. >> >> > 3. It only works for bpf maps that are defined explicitly in the bpf >> >> > code and not for implicit (inner) bpf maps (bss, rodata, etc). >> >> >> >> Ah, right. Well, other than that I don't think there's a way to set pin >> >> paths in bulk, other than by manually iterating and setting them one at >> >> a time. But, erm, can't you just do that? :) >> >> >> > >> > Sure, I can, but I think we should avoid that. As I said this forces >> > the user to know libbpf's pin path naming algorithm, which is not part >> > of the libbpf api afaik. >> >> Why? If you set the pin path from your application, libbpf will also try >> to reuse the map from that path. So you don't need to know libbpf's >> algorithm if you just override it with your own paths? >> > > If I do bpf_object__pin_maps then libbpf decides where it wants to pin > them. I can set each path by my own, but then why do we need this > function? Erm, what do you mean, "libbpf decides". bpf_object__pin_maps(obj, path) does exactly what you're asking for: If you supply the path, all maps are going to be pinned by name underneath that directory... > All It does is pinning all the maps at paths that are not part of the > api. In this libbpf version it is here, in the next it is there, and > user code will need to change accordingly. Why would you assume the paths would change? That would be an API break? > For example, libbpf today uses <path>/<map_name> as the pin path, but > it is also doing sanitize_pin_path on each path. This means that after > if use bpf_object__pin_maps I also need to know how libbpf sanitizes > its paths and mimic that behavior on my side. The paths are sanitised so the kernel will accept them. If you're using invalid paths your pinning is not going to work at all. If you just want the paths that the maps are pinned under, use bpf_map__get_pin_path(). >> > I think that if we have a method to pin all maps at a specific path >> > there should also be a method for reusing them all from this path, >> > either by exposing the function that builds the pin path, or a >> > function that sets all the paths from a root path. >> >> What you're asking for is basically a function >> bpf_object__set_all_pin_paths(obj, path) >> >> instead of having to do >> >> bpf_object__for_each_map(map, obj) { >> sprintf(path, "path/%s", bpf_map__name(map)); >> bpf_map__set_pin_path(map, path); >> } >> >> or? Is that really needed? >> > > Yes, that is what I am asking for. Either that or a > bpf_map__build_pin_path(path, map) That will return a pin path that is > compatible with libbpf's one, and then I can iterate over all maps. See above; this is what bpf_object__pin_maps() does today? -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 17:55 ` Toke Høiland-Jørgensen @ 2021-02-08 18:19 ` Gilad Reti 2021-02-08 19:16 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Gilad Reti @ 2021-02-08 18:19 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: bpf, Andrii Nakryiko On Mon, Feb 8, 2021 at 7:55 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Gilad Reti <gilad.reti@gmail.com> writes: > > > On Mon, Feb 8, 2021 at 5:09 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> > >> Gilad Reti <gilad.reti@gmail.com> writes: > >> > >> > On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> >> > >> >> Gilad Reti <gilad.reti@gmail.com> writes: > >> >> > >> >> > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> >> >> > >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: > >> >> >> > >> >> >> > Also, is there a way to set the pin path to all maps/programs at once? > >> >> >> > For example, bpf_object__pin_maps pins all maps at a specific path, > >> >> >> > but as far as I was able to find there is no similar function to set > >> >> >> > the pin path for all maps only (without pinning) so that at loading > >> >> >> > time libbpf will try to reuse all maps. The only way to achieve a > >> >> >> > complete reuse of all maps that I could find is to "reverse engineer" > >> >> >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and > >> >> >> > set the pin path on each map before load. > >> >> >> > >> >> >> You can set the 'pinning' attribute in the map definition - add > >> >> >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default > >> >> >> this will pin beneath /sys/fs/bpf, but you can customise that by setting > >> >> >> the pin_root_path attribute in bpf_object_open_opts. > >> >> > > >> >> > Yes, I am familiar with that feature, but it has some downsides: > >> >> > 1. I need to set it manually on every map (and in cases that I have > >> >> > only the compiled object file that would be hard). > >> >> > 2. It only works for bpf maps and not bpf programs. > >> >> > 3. It only works for bpf maps that are defined explicitly in the bpf > >> >> > code and not for implicit (inner) bpf maps (bss, rodata, etc). > >> >> > >> >> Ah, right. Well, other than that I don't think there's a way to set pin > >> >> paths in bulk, other than by manually iterating and setting them one at > >> >> a time. But, erm, can't you just do that? :) > >> >> > >> > > >> > Sure, I can, but I think we should avoid that. As I said this forces > >> > the user to know libbpf's pin path naming algorithm, which is not part > >> > of the libbpf api afaik. > >> > >> Why? If you set the pin path from your application, libbpf will also try > >> to reuse the map from that path. So you don't need to know libbpf's > >> algorithm if you just override it with your own paths? > >> > > > > If I do bpf_object__pin_maps then libbpf decides where it wants to pin > > them. I can set each path by my own, but then why do we need this > > function? > > Erm, what do you mean, "libbpf decides". bpf_object__pin_maps(obj, path) > does exactly what you're asking for: If you supply the path, all maps > are going to be pinned by name underneath that directory... They are pinned under this directory, but with which filename? Today libbpf builds the filename by taking the map name and escaping it, but what will happen if this will have to change? For example, libbpf pins programs by thier section name, but as I mentioned in the first message in this thread this causes failures when multiple programs reside in one section, so we may need to change the naming and this can break user code. > > > All It does is pinning all the maps at paths that are not part of the > > api. In this libbpf version it is here, in the next it is there, and > > user code will need to change accordingly. > > Why would you assume the paths would change? That would be an API break? The point that I am trying to make is that this naming convention is libbpf internal, so either it should be defined as a part of the api and each user will need to implement the same naming logic on his side (escaping etc), relying on libbpf implementation to remain consistent (this may be the case right now) but for in cases like the program pinning for example api will have to break, or just expose the pinning path as another api and then libbpf will need to make no guarantees about his naming convention. > > > For example, libbpf today uses <path>/<map_name> as the pin path, but > > it is also doing sanitize_pin_path on each path. This means that after > > if use bpf_object__pin_maps I also need to know how libbpf sanitizes > > its paths and mimic that behavior on my side. > > The paths are sanitised so the kernel will accept them. If you're using > invalid paths your pinning is not going to work at all. If you just want > the paths that the maps are pinned under, use bpf_map__get_pin_path(). > I am not saying that sanitization is redundant, but rather that it needs to be properly defined (i.e. all dots will always be replaced with underscores), so either expose it in the api or document it so that users don't have to look after the specific implementation. Of course I can retrieve that paths after pinning, but this is sounds like sort of a workaround to me, though I am okay with staying this way. The problem that I have with this approach is that if other processes want to reuse the same map they will have to share the pinning path somehow instead of each one retreiving it from the map directly. > >> > I think that if we have a method to pin all maps at a specific path > >> > there should also be a method for reusing them all from this path, > >> > either by exposing the function that builds the pin path, or a > >> > function that sets all the paths from a root path. > >> > >> What you're asking for is basically a function > >> bpf_object__set_all_pin_paths(obj, path) > >> > >> instead of having to do > >> > >> bpf_object__for_each_map(map, obj) { > >> sprintf(path, "path/%s", bpf_map__name(map)); > >> bpf_map__set_pin_path(map, path); > >> } > >> > >> or? Is that really needed? > >> > > > > Yes, that is what I am asking for. Either that or a > > bpf_map__build_pin_path(path, map) That will return a pin path that is > > compatible with libbpf's one, and then I can iterate over all maps. > > See above; this is what bpf_object__pin_maps() does today? I didn't get this last comment. What I meant is that I want something like the bpf_object__pin_maps but that doesn't pin the maps, just exposing its naming part. > > -Toke > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 18:19 ` Gilad Reti @ 2021-02-08 19:16 ` Toke Høiland-Jørgensen 2021-02-09 8:35 ` Gilad Reti 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-08 19:16 UTC (permalink / raw) To: Gilad Reti; +Cc: bpf, Andrii Nakryiko Gilad Reti <gilad.reti@gmail.com> writes: > On Mon, Feb 8, 2021 at 7:55 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> > On Mon, Feb 8, 2021 at 5:09 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> >> >> > On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> >> >> >> >> > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> >> >> >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: >> >> >> >> >> >> >> >> > Also, is there a way to set the pin path to all maps/programs at once? >> >> >> >> > For example, bpf_object__pin_maps pins all maps at a specific path, >> >> >> >> > but as far as I was able to find there is no similar function to set >> >> >> >> > the pin path for all maps only (without pinning) so that at loading >> >> >> >> > time libbpf will try to reuse all maps. The only way to achieve a >> >> >> >> > complete reuse of all maps that I could find is to "reverse engineer" >> >> >> >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and >> >> >> >> > set the pin path on each map before load. >> >> >> >> >> >> >> >> You can set the 'pinning' attribute in the map definition - add >> >> >> >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default >> >> >> >> this will pin beneath /sys/fs/bpf, but you can customise that by setting >> >> >> >> the pin_root_path attribute in bpf_object_open_opts. >> >> >> > >> >> >> > Yes, I am familiar with that feature, but it has some downsides: >> >> >> > 1. I need to set it manually on every map (and in cases that I have >> >> >> > only the compiled object file that would be hard). >> >> >> > 2. It only works for bpf maps and not bpf programs. >> >> >> > 3. It only works for bpf maps that are defined explicitly in the bpf >> >> >> > code and not for implicit (inner) bpf maps (bss, rodata, etc). >> >> >> >> >> >> Ah, right. Well, other than that I don't think there's a way to set pin >> >> >> paths in bulk, other than by manually iterating and setting them one at >> >> >> a time. But, erm, can't you just do that? :) >> >> >> >> >> > >> >> > Sure, I can, but I think we should avoid that. As I said this forces >> >> > the user to know libbpf's pin path naming algorithm, which is not part >> >> > of the libbpf api afaik. >> >> >> >> Why? If you set the pin path from your application, libbpf will also try >> >> to reuse the map from that path. So you don't need to know libbpf's >> >> algorithm if you just override it with your own paths? >> >> >> > >> > If I do bpf_object__pin_maps then libbpf decides where it wants to pin >> > them. I can set each path by my own, but then why do we need this >> > function? >> >> Erm, what do you mean, "libbpf decides". bpf_object__pin_maps(obj, path) >> does exactly what you're asking for: If you supply the path, all maps >> are going to be pinned by name underneath that directory... > > They are pinned under this directory, but with which filename? Today > libbpf builds the filename by taking the map name and escaping it, but > what will happen if this will have to change? Then that would have to be done in a way that was backwards-compatible so as not to break user code :) >> > For example, libbpf today uses <path>/<map_name> as the pin path, but >> > it is also doing sanitize_pin_path on each path. This means that after >> > if use bpf_object__pin_maps I also need to know how libbpf sanitizes >> > its paths and mimic that behavior on my side. >> >> The paths are sanitised so the kernel will accept them. If you're using >> invalid paths your pinning is not going to work at all. If you just want >> the paths that the maps are pinned under, use bpf_map__get_pin_path(). >> > > I am not saying that sanitization is redundant, but rather that it > needs to be properly defined (i.e. all dots will always be replaced > with underscores), so either expose it in the api or document it so > that users don't have to look after the specific implementation. Lack of documentation is a perennial problem, and patches are always welcome. But it is API: libbpf does things a certain way today, and if it changes in a way that will break user programs, that is an API break. >> >> > I think that if we have a method to pin all maps at a specific path >> >> > there should also be a method for reusing them all from this path, >> >> > either by exposing the function that builds the pin path, or a >> >> > function that sets all the paths from a root path. >> >> >> >> What you're asking for is basically a function >> >> bpf_object__set_all_pin_paths(obj, path) >> >> >> >> instead of having to do >> >> >> >> bpf_object__for_each_map(map, obj) { >> >> sprintf(path, "path/%s", bpf_map__name(map)); >> >> bpf_map__set_pin_path(map, path); >> >> } >> >> >> >> or? Is that really needed? >> >> >> > >> > Yes, that is what I am asking for. Either that or a >> > bpf_map__build_pin_path(path, map) That will return a pin path that is >> > compatible with libbpf's one, and then I can iterate over all maps. >> >> See above; this is what bpf_object__pin_maps() does today? > > I didn't get this last comment. What I meant is that I want something > like the bpf_object__pin_maps but that doesn't pin the maps, just > exposing its naming part. Right, OK. Why, though? I can kinda see how it could be convenient to (basically )make libbpf behave as if all maps has the 'pinning' attribute set, for map reuse. But I'm not sure I can think any concrete use cases where this would be needed. What's yours? -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-08 19:16 ` Toke Høiland-Jørgensen @ 2021-02-09 8:35 ` Gilad Reti 2021-02-09 11:03 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Gilad Reti @ 2021-02-09 8:35 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: bpf, Andrii Nakryiko On Mon, Feb 8, 2021 at 9:16 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Gilad Reti <gilad.reti@gmail.com> writes: > > > On Mon, Feb 8, 2021 at 7:55 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> > >> Gilad Reti <gilad.reti@gmail.com> writes: > >> > >> > On Mon, Feb 8, 2021 at 5:09 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> >> > >> >> Gilad Reti <gilad.reti@gmail.com> writes: > >> >> > >> >> > On Mon, Feb 8, 2021 at 4:28 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> >> >> > >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: > >> >> >> > >> >> >> > On Mon, Feb 8, 2021 at 1:42 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > >> >> >> >> > >> >> >> >> Gilad Reti <gilad.reti@gmail.com> writes: > >> >> >> >> > >> >> >> >> > Also, is there a way to set the pin path to all maps/programs at once? > >> >> >> >> > For example, bpf_object__pin_maps pins all maps at a specific path, > >> >> >> >> > but as far as I was able to find there is no similar function to set > >> >> >> >> > the pin path for all maps only (without pinning) so that at loading > >> >> >> >> > time libbpf will try to reuse all maps. The only way to achieve a > >> >> >> >> > complete reuse of all maps that I could find is to "reverse engineer" > >> >> >> >> > libbpf's pin path generation algorithm (i.e. <path>/<map_name>) and > >> >> >> >> > set the pin path on each map before load. > >> >> >> >> > >> >> >> >> You can set the 'pinning' attribute in the map definition - add > >> >> >> >> '__uint(pinning, LIBBPF_PIN_BY_NAME);' to the map struct. By default > >> >> >> >> this will pin beneath /sys/fs/bpf, but you can customise that by setting > >> >> >> >> the pin_root_path attribute in bpf_object_open_opts. > >> >> >> > > >> >> >> > Yes, I am familiar with that feature, but it has some downsides: > >> >> >> > 1. I need to set it manually on every map (and in cases that I have > >> >> >> > only the compiled object file that would be hard). > >> >> >> > 2. It only works for bpf maps and not bpf programs. > >> >> >> > 3. It only works for bpf maps that are defined explicitly in the bpf > >> >> >> > code and not for implicit (inner) bpf maps (bss, rodata, etc). > >> >> >> > >> >> >> Ah, right. Well, other than that I don't think there's a way to set pin > >> >> >> paths in bulk, other than by manually iterating and setting them one at > >> >> >> a time. But, erm, can't you just do that? :) > >> >> >> > >> >> > > >> >> > Sure, I can, but I think we should avoid that. As I said this forces > >> >> > the user to know libbpf's pin path naming algorithm, which is not part > >> >> > of the libbpf api afaik. > >> >> > >> >> Why? If you set the pin path from your application, libbpf will also try > >> >> to reuse the map from that path. So you don't need to know libbpf's > >> >> algorithm if you just override it with your own paths? > >> >> > >> > > >> > If I do bpf_object__pin_maps then libbpf decides where it wants to pin > >> > them. I can set each path by my own, but then why do we need this > >> > function? > >> > >> Erm, what do you mean, "libbpf decides". bpf_object__pin_maps(obj, path) > >> does exactly what you're asking for: If you supply the path, all maps > >> are going to be pinned by name underneath that directory... > > > > They are pinned under this directory, but with which filename? Today > > libbpf builds the filename by taking the map name and escaping it, but > > what will happen if this will have to change? > > Then that would have to be done in a way that was backwards-compatible > so as not to break user code :) > > >> > For example, libbpf today uses <path>/<map_name> as the pin path, but > >> > it is also doing sanitize_pin_path on each path. This means that after > >> > if use bpf_object__pin_maps I also need to know how libbpf sanitizes > >> > its paths and mimic that behavior on my side. > >> > >> The paths are sanitised so the kernel will accept them. If you're using > >> invalid paths your pinning is not going to work at all. If you just want > >> the paths that the maps are pinned under, use bpf_map__get_pin_path(). > >> > > > > I am not saying that sanitization is redundant, but rather that it > > needs to be properly defined (i.e. all dots will always be replaced > > with underscores), so either expose it in the api or document it so > > that users don't have to look after the specific implementation. > > Lack of documentation is a perennial problem, and patches are always > welcome. But it is API: libbpf does things a certain way today, and if > it changes in a way that will break user programs, that is an API break. > Okay than, you got me convinced. If we agree that sanitization etc is all part of the api then I am fine with the current state. I am still somewhat uncomfortable with forcing the user to read libbpf's source code just to find out the implementation details, but it may be that we only need more documentation. > >> >> > I think that if we have a method to pin all maps at a specific path > >> >> > there should also be a method for reusing them all from this path, > >> >> > either by exposing the function that builds the pin path, or a > >> >> > function that sets all the paths from a root path. > >> >> > >> >> What you're asking for is basically a function > >> >> bpf_object__set_all_pin_paths(obj, path) > >> >> > >> >> instead of having to do > >> >> > >> >> bpf_object__for_each_map(map, obj) { > >> >> sprintf(path, "path/%s", bpf_map__name(map)); > >> >> bpf_map__set_pin_path(map, path); > >> >> } > >> >> > >> >> or? Is that really needed? > >> >> > >> > > >> > Yes, that is what I am asking for. Either that or a > >> > bpf_map__build_pin_path(path, map) That will return a pin path that is > >> > compatible with libbpf's one, and then I can iterate over all maps. > >> > >> See above; this is what bpf_object__pin_maps() does today? > > > > I didn't get this last comment. What I meant is that I want something > > like the bpf_object__pin_maps but that doesn't pin the maps, just > > exposing its naming part. > > Right, OK. Why, though? I can kinda see how it could be convenient to > (basically )make libbpf behave as if all maps has the 'pinning' > attribute set, for map reuse. But I'm not sure I can think any concrete > use cases where this would be needed. What's yours? > I am using the same bpf objects (more specifically, the new skeleton feature) in two different processes that need access to the same maps/programs (for example, they both need access to shared maps). Thus, I want to reuse the entire object in both. Since we already have a way to pin an entire bpf object, I thought it would be convenient to have a way of reusing it entirely (though I am fine with pinning and reusing each one manually). (I cannot set the __uint(pinning, LIBBPF_PIN_BY_NAME) on each since I want to share the bss map too) > -Toke > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-09 8:35 ` Gilad Reti @ 2021-02-09 11:03 ` Toke Høiland-Jørgensen 2021-02-10 20:04 ` Andrii Nakryiko 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2021-02-09 11:03 UTC (permalink / raw) To: Gilad Reti; +Cc: bpf, Andrii Nakryiko Gilad Reti <gilad.reti@gmail.com> writes: >> > I didn't get this last comment. What I meant is that I want something >> > like the bpf_object__pin_maps but that doesn't pin the maps, just >> > exposing its naming part. >> >> Right, OK. Why, though? I can kinda see how it could be convenient to >> (basically )make libbpf behave as if all maps has the 'pinning' >> attribute set, for map reuse. But I'm not sure I can think any concrete >> use cases where this would be needed. What's yours? >> > > I am using the same bpf objects (more specifically, the new skeleton > feature) in two different processes that need access to the same > maps/programs (for example, they both need access to shared maps). > Thus, I want to reuse the entire object in both. Since we already have > a way to pin an entire bpf object, I thought it would be convenient to > have a way of reusing it entirely (though I am fine with pinning and > reusing each one manually). > (I cannot set the __uint(pinning, LIBBPF_PIN_BY_NAME) on each since I > want to share the bss map too) Ah, see, now *this* could go under the "missing API" header: having a way to make libbpf pin (and reuse) the auto-generated maps, like you can do with the 'pinning' attribute. Andrii, WDYT? -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-09 11:03 ` Toke Høiland-Jørgensen @ 2021-02-10 20:04 ` Andrii Nakryiko 0 siblings, 0 replies; 15+ messages in thread From: Andrii Nakryiko @ 2021-02-10 20:04 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: Gilad Reti, bpf, Andrii Nakryiko On Tue, Feb 9, 2021 at 3:03 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > Gilad Reti <gilad.reti@gmail.com> writes: > > >> > I didn't get this last comment. What I meant is that I want something > >> > like the bpf_object__pin_maps but that doesn't pin the maps, just > >> > exposing its naming part. > >> > >> Right, OK. Why, though? I can kinda see how it could be convenient to > >> (basically )make libbpf behave as if all maps has the 'pinning' > >> attribute set, for map reuse. But I'm not sure I can think any concrete > >> use cases where this would be needed. What's yours? > >> > > > > I am using the same bpf objects (more specifically, the new skeleton > > feature) in two different processes that need access to the same > > maps/programs (for example, they both need access to shared maps). > > Thus, I want to reuse the entire object in both. Since we already have > > a way to pin an entire bpf object, I thought it would be convenient to > > have a way of reusing it entirely (though I am fine with pinning and > > reusing each one manually). > > (I cannot set the __uint(pinning, LIBBPF_PIN_BY_NAME) on each since I > > want to share the bss map too) > > Ah, see, now *this* could go under the "missing API" header: having a > way to make libbpf pin (and reuse) the auto-generated maps, like you can > do with the 'pinning' attribute. > > Andrii, WDYT? I think that the whole pinning handling in libbpf feels a bit ad-hoc. It would be good for someone to sit and think through this end-to-end. Unfortunately I never had a need for pinning, so I'm not the best person to do this. In this case, you can still do bpf_map__set_pin_path() on internal maps (.bss, .data, etc), but you'll need to specify pin path explicitly, which is different from what you get with LIBBPF_PIN_BY_NAME. So I think pinning support is not complete, but I'd also like to avoid adding new APIs in an ad-hoc manner without a holistic view of how pinning should work with libbpf. > > -Toke > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: libbpf: pinning multiple progs from the same section 2021-02-07 11:35 libbpf: pinning multiple progs from the same section Gilad Reti 2021-02-08 8:57 ` Gilad Reti @ 2021-02-08 22:36 ` Andrii Nakryiko 1 sibling, 0 replies; 15+ messages in thread From: Andrii Nakryiko @ 2021-02-08 22:36 UTC (permalink / raw) To: Gilad Reti; +Cc: bpf, Andrii Nakryiko On Sun, Feb 7, 2021 at 3:36 AM Gilad Reti <gilad.reti@gmail.com> wrote: > > Hello there, > > Last year, libbpf added support for attaching multiple handlers to the > same event by allowing defining multiple progs in the same elf > section. However, the pin path for a bpf program is obtained via the > __bpf_program__pin_name function, which uses an escaped version of the > elf section name as the pin_name. Thus, trying to pin multiple bpf > programs defined on the same section fails with "File exists" error, > since libbpf tries to pin more than one program on a single path. > Does adding the actual program name to the pin path makes sense? Yes it does, but as Toke mentioned, that would be API-breaking change, so I'm holding that off to major version bump or at least until we agree that it's OK to change this behavior from the current nonsensical one. > > Thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-02-10 20:05 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-07 11:35 libbpf: pinning multiple progs from the same section Gilad Reti 2021-02-08 8:57 ` Gilad Reti 2021-02-08 11:42 ` Toke Høiland-Jørgensen 2021-02-08 11:57 ` Gilad Reti 2021-02-08 14:28 ` Toke Høiland-Jørgensen 2021-02-08 14:44 ` Gilad Reti 2021-02-08 15:09 ` Toke Høiland-Jørgensen 2021-02-08 15:50 ` Gilad Reti 2021-02-08 17:55 ` Toke Høiland-Jørgensen 2021-02-08 18:19 ` Gilad Reti 2021-02-08 19:16 ` Toke Høiland-Jørgensen 2021-02-09 8:35 ` Gilad Reti 2021-02-09 11:03 ` Toke Høiland-Jørgensen 2021-02-10 20:04 ` Andrii Nakryiko 2021-02-08 22:36 ` Andrii Nakryiko
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).