Re: [PATCH bpf-next 1/4] libbpf: streamline low-level XDP APIs

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Andrii Nakryiko <andrii@kernel.org> writes:

> Introduce 4 new netlink-based XDP APIs for attaching, detaching, and
> querying XDP programs:
>   - bpf_xdp_attach;
>   - bpf_xdp_detach;
>   - bpf_xdp_query;
>   - bpf_xdp_query_id.
>
> These APIs replace bpf_set_link_xdp_fd, bpf_set_link_xdp_fd_opts,
> bpf_get_link_xdp_id, and bpf_get_link_xdp_info APIs ([0]). The latter
> don't follow a consistent naming pattern and some of them use
> non-extensible approaches (e.g., struct xdp_link_info which can't be
> modified without breaking libbpf ABI).
>
> The approach I took with these low-level XDP APIs is similar to what we
> did with low-level TC APIs. There is a nice duality of bpf_tc_attach vs
> bpf_xdp_attach, and so on. I left bpf_xdp_attach() to support detaching
> when -1 is specified for prog_fd for generality and convenience, but
> bpf_xdp_detach() is preferred due to clearer naming and associated
> semantics. Both bpf_xdp_attach() and bpf_xdp_detach() accept the same
> opts struct allowing to specify expected old_prog_fd.
>
> While doing the refactoring, I noticed that old APIs require users to
> specify opts with old_fd == -1 to declare "don't care about already
> attached XDP prog fd" condition. Otherwise, FD 0 is assumed, which is
> essentially never an intended behavior. So I made this behavior
> consistent with other kernel and libbpf APIs, in which zero FD means "no
> FD". This seems to be more in line with the latest thinking in BPF land
> and should cause less user confusion, hopefully.
>
> For querying, I left two APIs, both more generic bpf_xdp_query()
> allowing to query multiple IDs and attach mode, but also
> a specialization of it, bpf_xdp_query_id(), which returns only requested
> prog_id. Uses of prog_id returning bpf_get_link_xdp_id() were so
> prevalent across selftests and samples, that it seemed a very common use
> case and using bpf_xdp_query() for doing it felt very cumbersome with
> a highly branches if/else chain based on flags and attach mode.
>
> Old APIs are scheduled for deprecation in libbpf 0.8 release.
>
>   [0] Closes: https://github.com/libbpf/libbpf/issues/309
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>