From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: ast@kernel.org, andrii@kernel.org, martin.lau@linux.dev,
razor@blackwall.org, sdf@google.com, john.fastabend@gmail.com,
kuba@kernel.org, dxu@dxuuu.xyz, joe@cilium.io, toke@kernel.org,
davem@davemloft.net, bpf@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 4/7] libbpf: Add link-based API for tcx
Date: Thu, 8 Jun 2023 14:45:48 -0700 [thread overview]
Message-ID: <CAEf4Bzaey8c86vLh8sMfvU5KepbYOuej0cKXb88ANp8kZnpCQQ@mail.gmail.com> (raw)
In-Reply-To: <20230607192625.22641-5-daniel@iogearbox.net>
On Wed, Jun 7, 2023 at 12:26 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Implement tcx BPF link support for libbpf.
>
> The bpf_program__attach_fd_opts() API has been refactored slightly in order to
> pass bpf_link_create_opts pointer as input.
>
> A new bpf_program__attach_tcx_opts() has been added on top of this which allows
> for passing all relevant data via extensible struct bpf_tcx_opts.
>
> The program sections tcx/ingress and tcx/egress correspond to the hook locations
> for tc ingress and egress, respectively.
>
> For concrete usage examples, see the extensive selftests that have been
> developed as part of this series.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> tools/lib/bpf/bpf.c | 5 +++++
> tools/lib/bpf/bpf.h | 7 +++++++
> tools/lib/bpf/libbpf.c | 44 +++++++++++++++++++++++++++++++++++-----
> tools/lib/bpf/libbpf.h | 17 ++++++++++++++++
> tools/lib/bpf/libbpf.map | 1 +
> 5 files changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index a3d1b7ebe224..c340d3cbc6bd 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -746,6 +746,11 @@ int bpf_link_create(int prog_fd, int target_fd,
> if (!OPTS_ZEROED(opts, tracing))
> return libbpf_err(-EINVAL);
> break;
> + case BPF_TCX_INGRESS:
> + case BPF_TCX_EGRESS:
> + attr.link_create.tcx.relative_fd = OPTS_GET(opts, tcx.relative_fd, 0);
> + attr.link_create.tcx.expected_revision = OPTS_GET(opts, tcx.expected_revision, 0);
can you also add an OPTS_ZEROED check like for other types of links?
> + break;
> default:
> if (!OPTS_ZEROED(opts, flags))
> return libbpf_err(-EINVAL);
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index 480c584a6f7f..12591516dca0 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -370,6 +370,13 @@ struct bpf_link_create_opts {
> struct {
> __u64 cookie;
> } tracing;
> + struct {
> + union {
> + __u32 relative_fd;
> + __u32 relative_id;
> + };
same comment about union, let's not add it and have two separate fields
> + __u32 expected_revision;
> + } tcx;
> };
> size_t :0;
> };
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b89127471c6a..d7b6ff49f02e 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -133,6 +133,7 @@ static const char * const link_type_name[] = {
> [BPF_LINK_TYPE_KPROBE_MULTI] = "kprobe_multi",
> [BPF_LINK_TYPE_STRUCT_OPS] = "struct_ops",
> [BPF_LINK_TYPE_NETFILTER] = "netfilter",
> + [BPF_LINK_TYPE_TCX] = "tcx",
> };
>
> static const char * const map_type_name[] = {
> @@ -11685,11 +11686,10 @@ static int attach_lsm(const struct bpf_program *prog, long cookie, struct bpf_li
> }
>
> static struct bpf_link *
> -bpf_program__attach_fd(const struct bpf_program *prog, int target_fd, int btf_id,
> - const char *target_name)
> +bpf_program__attach_fd_opts(const struct bpf_program *prog,
> + const struct bpf_link_create_opts *opts,
> + int target_fd, const char *target_name)
nit: please keep opts as the last argument
> {
> - DECLARE_LIBBPF_OPTS(bpf_link_create_opts, opts,
> - .target_btf_id = btf_id);
> enum bpf_attach_type attach_type;
> char errmsg[STRERR_BUFSIZE];
> struct bpf_link *link;
> @@ -11707,7 +11707,7 @@ bpf_program__attach_fd(const struct bpf_program *prog, int target_fd, int btf_id
> link->detach = &bpf_link__detach_fd;
>
> attach_type = bpf_program__expected_attach_type(prog);
> - link_fd = bpf_link_create(prog_fd, target_fd, attach_type, &opts);
> + link_fd = bpf_link_create(prog_fd, target_fd, attach_type, opts);
> if (link_fd < 0) {
> link_fd = -errno;
> free(link);
> @@ -11720,6 +11720,17 @@ bpf_program__attach_fd(const struct bpf_program *prog, int target_fd, int btf_id
> return link;
> }
>
> +static struct bpf_link *
> +bpf_program__attach_fd(const struct bpf_program *prog, int target_fd, int btf_id,
> + const char *target_name)
> +{
> + LIBBPF_OPTS(bpf_link_create_opts, opts,
> + .target_btf_id = btf_id,
> + );
> +
> + return bpf_program__attach_fd_opts(prog, &opts, target_fd, target_name);
it seems like the only user of btf_id is bpf_program__attach_freplace,
so I'd just inline this there, and for all other 4 cases let's just
pass NULL as options?
That means we don't really need bpf_program__attach_fd_opts() and can
just add opts to bpf_program__attach_fd(). We'll have shorter name.
BTW, given it's not exposed API, let's drop double underscore and call
it just bpf_program_attach_fd()?
> +}
> +
> struct bpf_link *
> bpf_program__attach_cgroup(const struct bpf_program *prog, int cgroup_fd)
> {
> @@ -11738,6 +11749,29 @@ struct bpf_link *bpf_program__attach_xdp(const struct bpf_program *prog, int ifi
> return bpf_program__attach_fd(prog, ifindex, 0, "xdp");
> }
>
> +struct bpf_link *
> +bpf_program__attach_tcx_opts(const struct bpf_program *prog,
> + const struct bpf_tcx_opts *opts)
we don't have non-opts variant, so let's keep the name short (like we
did with bpf_program__attach_netlink): bpf_program__attach_tcx().
> +{
> + LIBBPF_OPTS(bpf_link_create_opts, link_create_opts);
> + int ifindex = OPTS_GET(opts, ifindex, 0);
let's not do OPTS_GET before we checked OPTS_VALID
> +
> + if (!OPTS_VALID(opts, bpf_tcx_opts))
> + return libbpf_err_ptr(-EINVAL);
> + if (!ifindex) {
> + pr_warn("prog '%s': target netdevice ifindex cannot be zero\n",
> + prog->name);
> + return libbpf_err_ptr(-EINVAL);
> + }
> +
> + link_create_opts.tcx.expected_revision = OPTS_GET(opts, expected_revision, 0);
> + link_create_opts.tcx.relative_fd = OPTS_GET(opts, relative_fd, 0);
> + link_create_opts.flags = OPTS_GET(opts, flags, 0);
> +
> + /* target_fd/target_ifindex use the same field in LINK_CREATE */
> + return bpf_program__attach_fd_opts(prog, &link_create_opts, ifindex, "tc");
> +}
> +
> struct bpf_link *bpf_program__attach_freplace(const struct bpf_program *prog,
> int target_fd,
> const char *attach_func_name)
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 754da73c643b..8ffba0f67c60 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -718,6 +718,23 @@ LIBBPF_API struct bpf_link *
> bpf_program__attach_freplace(const struct bpf_program *prog,
> int target_fd, const char *attach_func_name);
>
> +struct bpf_tcx_opts {
> + /* size of this struct, for forward/backward compatibility */
> + size_t sz;
> + int ifindex;
> + __u32 flags;
> + union {
> + __u32 relative_fd;
> + __u32 relative_id;
> + };
same thing about not using unions here :)
> + __u32 expected_revision;
and let's add `size_t :0;` to prevent compiler from leaving garbage
values in a padding at the end of the struct (once you drop union
there will be padding)
> +};
> +#define bpf_tcx_opts__last_field expected_revision
> +
> +LIBBPF_API struct bpf_link *
> +bpf_program__attach_tcx_opts(const struct bpf_program *prog,
> + const struct bpf_tcx_opts *opts);
> +
> struct bpf_map;
>
> LIBBPF_API struct bpf_link *bpf_map__attach_struct_ops(const struct bpf_map *map);
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index a29b90e9713c..f66b714512c2 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -396,4 +396,5 @@ LIBBPF_1.3.0 {
> global:
> bpf_obj_pin_opts;
> bpf_prog_detach_opts;
> + bpf_program__attach_tcx_opts;
> } LIBBPF_1.2.0;
> --
> 2.34.1
>
next prev parent reply other threads:[~2023-06-08 21:46 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 19:26 [PATCH bpf-next v2 0/7] BPF link support for tc BPF programs Daniel Borkmann
2023-06-07 19:26 ` [PATCH bpf-next v2 1/7] bpf: Add generic attach/detach/query API for multi-progs Daniel Borkmann
2023-06-08 17:23 ` Stanislav Fomichev
2023-06-08 20:59 ` Andrii Nakryiko
2023-06-08 21:52 ` Stanislav Fomichev
2023-06-08 22:13 ` Andrii Nakryiko
2023-06-08 23:06 ` Stanislav Fomichev
2023-06-08 23:54 ` Alexei Starovoitov
2023-06-09 0:08 ` Andrii Nakryiko
2023-06-09 0:38 ` Stanislav Fomichev
2023-06-09 0:29 ` Toke Høiland-Jørgensen
2023-06-09 6:52 ` Daniel Borkmann
2023-06-09 7:15 ` Daniel Borkmann
2023-06-09 11:04 ` Toke Høiland-Jørgensen
2023-06-09 12:34 ` Timo Beckers
2023-06-09 13:11 ` Toke Høiland-Jørgensen
2023-06-09 14:15 ` Daniel Borkmann
2023-06-09 16:41 ` Stanislav Fomichev
2023-06-09 19:03 ` Andrii Nakryiko
2023-06-10 2:52 ` Daniel Xu
2023-06-09 18:58 ` Andrii Nakryiko
2023-06-09 20:28 ` Toke Høiland-Jørgensen
2023-06-12 11:21 ` Dave Tucker
2023-06-12 12:43 ` Daniel Borkmann
2023-06-09 18:56 ` Andrii Nakryiko
2023-06-09 20:08 ` Alexei Starovoitov
[not found] ` <20230610022721.2950602-1-prankgup@fb.com>
2023-06-10 3:37 ` Alexei Starovoitov
2023-06-09 20:20 ` Toke Høiland-Jørgensen
2023-06-08 20:53 ` Andrii Nakryiko
2023-06-07 19:26 ` [PATCH bpf-next v2 2/7] bpf: Add fd-based tcx multi-prog infra with link support Daniel Borkmann
2023-06-08 1:25 ` Jamal Hadi Salim
2023-06-08 10:11 ` Daniel Borkmann
2023-06-08 19:46 ` Jamal Hadi Salim
2023-06-08 21:24 ` Andrii Nakryiko
2023-07-04 21:36 ` Jamal Hadi Salim
2023-07-04 22:01 ` Daniel Borkmann
2023-07-04 22:38 ` Jamal Hadi Salim
2023-07-05 7:34 ` Daniel Borkmann
2023-07-06 13:31 ` Jamal Hadi Salim
2023-06-08 17:50 ` Stanislav Fomichev
2023-06-08 21:20 ` Andrii Nakryiko
2023-06-09 3:06 ` Jakub Kicinski
2023-06-07 19:26 ` [PATCH bpf-next v2 3/7] libbpf: Add opts-based attach/detach/query API for tcx Daniel Borkmann
2023-06-08 21:37 ` Andrii Nakryiko
2023-06-07 19:26 ` [PATCH bpf-next v2 4/7] libbpf: Add link-based " Daniel Borkmann
2023-06-08 21:45 ` Andrii Nakryiko [this message]
2023-06-07 19:26 ` [PATCH bpf-next v2 5/7] bpftool: Extend net dump with tcx progs Daniel Borkmann
2023-06-07 19:26 ` [PATCH bpf-next v2 6/7] selftests/bpf: Add mprog API tests for BPF tcx opts Daniel Borkmann
2023-06-07 19:26 ` [PATCH bpf-next v2 7/7] selftests/bpf: Add mprog API tests for BPF tcx links Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEf4Bzaey8c86vLh8sMfvU5KepbYOuej0cKXb88ANp8kZnpCQQ@mail.gmail.com \
--to=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dxu@dxuuu.xyz \
--cc=joe@cilium.io \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
--cc=sdf@google.com \
--cc=toke@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).