* [PATCH bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton
@ 2024-06-18 18:38 Andrii Nakryiko
2024-06-18 19:56 ` Quentin Monnet
2024-06-21 18:00 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 3+ messages in thread
From: Andrii Nakryiko @ 2024-06-18 18:38 UTC (permalink / raw)
To: bpf, ast, daniel, martin.lau; +Cc: tj, void, Andrii Nakryiko
New versions of bpftool now emit additional link placeholders for BPF
maps (struct_ops maps are the only maps right now that support
attachment), and set up BPF skeleton in such a way that libbpf will
auto-attach BPF maps automatically, assumming libbpf is recent enough
(v1.5+). Old libbpf will do nothing with those links and won't attempt
to auto-attach maps. This allows user code to handle both pre-v1.5 and
v1.5+ versions of libbpf at runtime, if necessary.
But if users don't have (or don't want to) control bpftool version that
generates skeleton, then they can't just assume that skeleton will have
link placeholders. To make this detection possible and easy, let's add
the following to generated skeleton header file:
#define BPF_SKEL_SUPPORTS_MAP_AUTO_ATTACH 1
This can be used during compilation time to guard code that accesses
skel->links.<map> slots.
Note, if auto-attachment is undesirable, libbpf allows to disable this
through bpf_map__set_autoattach(map, false). This is necessary only on
libbpf v1.5+, older libbpf doesn't support map auto-attach anyways.
Libbpf version can be detected at compilation time using
LIBBPF_MAJOR_VERSION and LIBBPF_MINOR_VERSION macros, or at runtime with
libbpf_major_version() and libbpf_minor_version() APIs.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
tools/bpf/bpftool/gen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
index 4a4eedfcd479..51eaed76db97 100644
--- a/tools/bpf/bpftool/gen.c
+++ b/tools/bpf/bpftool/gen.c
@@ -1272,6 +1272,8 @@ static int do_skeleton(int argc, char **argv)
#include <stdlib.h> \n\
#include <bpf/libbpf.h> \n\
\n\
+ #define BPF_SKEL_SUPPORTS_MAP_AUTO_ATTACH 1 \n\
+ \n\
struct %1$s { \n\
struct bpf_object_skeleton *skeleton; \n\
struct bpf_object *obj; \n\
--
2.43.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton
2024-06-18 18:38 [PATCH bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton Andrii Nakryiko
@ 2024-06-18 19:56 ` Quentin Monnet
2024-06-21 18:00 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: Quentin Monnet @ 2024-06-18 19:56 UTC (permalink / raw)
To: Andrii Nakryiko, bpf, ast, daniel, martin.lau; +Cc: tj, void
On 18/06/2024 19:38, Andrii Nakryiko wrote:
> New versions of bpftool now emit additional link placeholders for BPF
> maps (struct_ops maps are the only maps right now that support
> attachment), and set up BPF skeleton in such a way that libbpf will
> auto-attach BPF maps automatically, assumming libbpf is recent enough
> (v1.5+). Old libbpf will do nothing with those links and won't attempt
> to auto-attach maps. This allows user code to handle both pre-v1.5 and
> v1.5+ versions of libbpf at runtime, if necessary.
>
> But if users don't have (or don't want to) control bpftool version that
> generates skeleton, then they can't just assume that skeleton will have
> link placeholders. To make this detection possible and easy, let's add
> the following to generated skeleton header file:
>
> #define BPF_SKEL_SUPPORTS_MAP_AUTO_ATTACH 1
>
> This can be used during compilation time to guard code that accesses
> skel->links.<map> slots.
>
> Note, if auto-attachment is undesirable, libbpf allows to disable this
> through bpf_map__set_autoattach(map, false). This is necessary only on
> libbpf v1.5+, older libbpf doesn't support map auto-attach anyways.
>
> Libbpf version can be detected at compilation time using
> LIBBPF_MAJOR_VERSION and LIBBPF_MINOR_VERSION macros, or at runtime with
> libbpf_major_version() and libbpf_minor_version() APIs.
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Looks good, thanks.
Acked-by: Quentin Monnet <qmo@kernel.org>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton
2024-06-18 18:38 [PATCH bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton Andrii Nakryiko
2024-06-18 19:56 ` Quentin Monnet
@ 2024-06-21 18:00 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2024-06-21 18:00 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: bpf, ast, daniel, martin.lau, tj, void
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:
On Tue, 18 Jun 2024 11:38:32 -0700 you wrote:
> New versions of bpftool now emit additional link placeholders for BPF
> maps (struct_ops maps are the only maps right now that support
> attachment), and set up BPF skeleton in such a way that libbpf will
> auto-attach BPF maps automatically, assumming libbpf is recent enough
> (v1.5+). Old libbpf will do nothing with those links and won't attempt
> to auto-attach maps. This allows user code to handle both pre-v1.5 and
> v1.5+ versions of libbpf at runtime, if necessary.
>
> [...]
Here is the summary with links:
- [bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton
https://git.kernel.org/bpf/bpf-next/c/651337c7ca82
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-06-21 18:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-18 18:38 [PATCH bpf-next] bpftool: allow compile-time checks of BPF map auto-attach support in skeleton Andrii Nakryiko
2024-06-18 19:56 ` Quentin Monnet
2024-06-21 18:00 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox