Re: [PATCH bpf-next v4 4/8] libbpf: Add link-based API for tcx

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Mon, Jul 10, 2023 at 1:12 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> Implement tcx BPF link support for libbpf.
>
> The bpf_program__attach_fd() API has been refactored slightly in order to pass
> bpf_link_create_opts pointer as input.
>
> A new bpf_program__attach_tcx() 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      | 19 ++++++++++--
>  tools/lib/bpf/bpf.h      |  5 ++++
>  tools/lib/bpf/libbpf.c   | 62 ++++++++++++++++++++++++++++++++++------
>  tools/lib/bpf/libbpf.h   | 16 +++++++++++
>  tools/lib/bpf/libbpf.map |  1 +
>  5 files changed, 92 insertions(+), 11 deletions(-)
>

Pretty minor nits, I think ifindex move to be mandatory argument is
the most consequential, as it's an API. With that addressed, please
add my ack for next rev

Acked-by: Andrii Nakryiko <andrii@kernel.org>

> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 3dfc43b477c3..d513c226b9aa 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -717,9 +717,9 @@ int bpf_link_create(int prog_fd, int target_fd,
>                     const struct bpf_link_create_opts *opts)
>  {
>         const size_t attr_sz = offsetofend(union bpf_attr, link_create);
> -       __u32 target_btf_id, iter_info_len;
> +       __u32 target_btf_id, iter_info_len, relative_id;
> +       int fd, err, relative;

nit: maybe make these new vars local to the TCX cases branch below?

>         union bpf_attr attr;
> -       int fd, err;
>
>         if (!OPTS_VALID(opts, bpf_link_create_opts))
>                 return libbpf_err(-EINVAL);
> @@ -781,6 +781,21 @@ int bpf_link_create(int prog_fd, int target_fd,
>                 if (!OPTS_ZEROED(opts, netfilter))
>                         return libbpf_err(-EINVAL);
>                 break;
> +       case BPF_TCX_INGRESS:
> +       case BPF_TCX_EGRESS:
> +               relative = OPTS_GET(opts, tcx.relative_fd, 0);
> +               relative_id = OPTS_GET(opts, tcx.relative_id, 0);
> +               if (relative > 0 && relative_id)
> +                       return libbpf_err(-EINVAL);
> +               if (relative_id) {
> +                       relative = relative_id;
> +                       attr.link_create.flags |= BPF_F_ID;
> +               }

Well, I have the same nit as in the previous patch, this "relative =
relative_id" is both confusing because of naming asymmetry (no
relative_fd throws me off), and also unnecessary updating of the
state. link_create.flags |= BPF_F_ID is inevitable, but the rest can
be more straightforward, IMO

> +               attr.link_create.tcx.relative_fd = relative;
> +               attr.link_create.tcx.expected_revision = OPTS_GET(opts, tcx.expected_revision, 0);
> +               if (!OPTS_ZEROED(opts, tcx))
> +                       return libbpf_err(-EINVAL);
> +               break;
>         default:
>                 if (!OPTS_ZEROED(opts, flags))
>                         return libbpf_err(-EINVAL);

[...]

> +struct bpf_link *
> +bpf_program__attach_tcx(const struct bpf_program *prog,
> +                       const struct bpf_tcx_opts *opts)
> +{
> +       LIBBPF_OPTS(bpf_link_create_opts, link_create_opts);
> +       __u32 relative_id, flags;
> +       int ifindex, relative_fd;
> +
> +       if (!OPTS_VALID(opts, bpf_tcx_opts))
> +               return libbpf_err_ptr(-EINVAL);
> +
> +       relative_id = OPTS_GET(opts, relative_id, 0);
> +       relative_fd = OPTS_GET(opts, relative_fd, 0);
> +       flags = OPTS_GET(opts, flags, 0);
> +       ifindex = OPTS_GET(opts, ifindex, 0);
> +
> +       /* validate we don't have unexpected combinations of non-zero fields */
> +       if (!ifindex) {
> +               pr_warn("prog '%s': target netdevice ifindex cannot be zero\n",
> +                       prog->name);
> +               return libbpf_err_ptr(-EINVAL);
> +       }

given ifindex is non-optional, then it makes more sense to have it as
a mandatory argument between prog and opts in
bpf_program__attach_tcx(), instead of as a field of an opts struct

> +       if (relative_fd > 0 && relative_id) {

this asymmetrical check is a bit distracting. And also, if someone
specifies negative FD and positive ID, that's also a bad combo and we
shouldn't just ignore invalid FD, right? So I'd have a nice and clean

if (relative_fd && relative_id) { /* bad */ }

> +               pr_warn("prog '%s': relative_fd and relative_id cannot be set at the same time\n",
> +                       prog->name);
> +               return libbpf_err_ptr(-EINVAL);
> +       }
> +       if (relative_id)
> +               flags |= BPF_F_ID;

I think bpf_link_create() will add this flag anyways, so can drop this
adjustment logic here?

> +
> +       link_create_opts.tcx.expected_revision = OPTS_GET(opts, expected_revision, 0);
> +       link_create_opts.tcx.relative_fd = relative_fd;
> +       link_create_opts.tcx.relative_id = relative_id;
> +       link_create_opts.flags = flags;
> +
> +       /* target_fd/target_ifindex use the same field in LINK_CREATE */
> +       return bpf_program_attach_fd(prog, ifindex, "tc", &link_create_opts);

s/tc/tcx/ ?

>  }
>
>  struct bpf_link *bpf_program__attach_freplace(const struct bpf_program *prog,
> @@ -11917,11 +11956,16 @@ struct bpf_link *bpf_program__attach_freplace(const struct bpf_program *prog,
>         }
>
>         if (target_fd) {
> +               LIBBPF_OPTS(bpf_link_create_opts, target_opts);
> +
>                 btf_id = libbpf_find_prog_btf_id(attach_func_name, target_fd);
>                 if (btf_id < 0)
>                         return libbpf_err_ptr(btf_id);
>
> -               return bpf_program__attach_fd(prog, target_fd, btf_id, "freplace");
> +               target_opts.target_btf_id = btf_id;
> +
> +               return bpf_program_attach_fd(prog, target_fd, "freplace",
> +                                            &target_opts);
>         } else {
>                 /* no target, so use raw_tracepoint_open for compatibility
>                  * with old kernels
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 10642ad69d76..33f60a318e81 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -733,6 +733,22 @@ LIBBPF_API struct bpf_link *
>  bpf_program__attach_netfilter(const struct bpf_program *prog,
>                               const struct bpf_netfilter_opts *opts);
>
> +struct bpf_tcx_opts {
> +       /* size of this struct, for forward/backward compatibility */
> +       size_t sz;
> +       int ifindex;

is ifindex optional or it's expected to always be specified? If the
latter, then I'd move ifindex out of opts and make it second arg of
bpf_program__attach_tcx, between prog and opts

> +       __u32 flags;
> +       __u32 relative_fd;
> +       __u32 relative_id;
> +       __u64 expected_revision;
> +       size_t :0;
> +};
> +#define bpf_tcx_opts__last_field expected_revision
> +
> +LIBBPF_API struct bpf_link *
> +bpf_program__attach_tcx(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 a95d39bbef90..2a2db5c78048 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -397,4 +397,5 @@ LIBBPF_1.3.0 {
>                 bpf_obj_pin_opts;
>                 bpf_program__attach_netfilter;
>                 bpf_prog_detach_opts;
> +               bpf_program__attach_tcx;

heh, now we definitely screwed up sorting ;)

>  } LIBBPF_1.2.0;

> --
> 2.34.1
>