• Andrii Nakryiko's avatar
    libbpf: streamline low-level XDP APIs · c359821a
    Andrii Nakryiko authored
    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/309Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
    Acked-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
    Link: https://lore.kernel.org/r/20220120061422.2710637-2-andrii@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
    c359821a
libbpf.map 9.37 KB