Re: [PATCH bpf-next v5 00/15] Introduce AF_XDP buffer allocation API

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Wed, May 20, 2020 at 12:21 PM Björn Töpel <bjorn.topel@gmail.com> wrote:
>
> Overview
> ========
>
> Driver adoption for AF_XDP has been slow. The amount of code required
> to proper support AF_XDP is substantial and the driver/core APIs are
> vague or even non-existing. Drivers have to manually adjust data
> offsets, updating AF_XDP handles differently for different modes
> (aligned/unaligned).
>
> This series attempts to improve the situation by introducing an AF_XDP
> buffer allocation API. The implementation is based on a single core
> (single producer/consumer) buffer pool for the AF_XDP UMEM.
>
> A buffer is allocated using the xsk_buff_alloc() function, and
> returned using xsk_buff_free(). If a buffer is disassociated with the
> pool, e.g. when a buffer is passed to an AF_XDP socket, a buffer is
> said to be released. Currently, the release function is only used by
> the AF_XDP internals and not visible to the driver.
>
> Drivers using this API should register the XDP memory model with the
> new MEM_TYPE_XSK_BUFF_POOL type, which will supersede the
> MEM_TYPE_ZERO_COPY type.
>
> The buffer type is struct xdp_buff, and follows the lifetime of
> regular xdp_buffs, i.e.  the lifetime of an xdp_buff is restricted to
> a NAPI context. In other words, the API is not replacing xdp_frames.
>
> DMA mapping/synching is folded into the buffer handling as well.
>
> @JeffK The Intel drivers changes should go through the bpf-next tree,
>        and not your regular Intel tree, since multiple (non-Intel)
>        drivers are affected.
>
> The outline of the series is as following:
>
> Patch 1 is a fix for xsk_umem_xdp_frame_sz().
>
> Patch 2 to 4 are restructures/clean ups. The XSKMAP implementation is
> moved to net/xdp/. Functions/defines/enums that are only used by the
> AF_XDP internals are moved from the global include/net/xdp_sock.h to
> net/xdp/xsk.h. We are also introducing a new "driver include file",
> include/net/xdp_sock_drv.h, which is the only file NIC driver
> developers adding AF_XDP zero-copy support should care about.
>
> Patch 5 adds the new API, and migrates the "copy-mode"/skb-mode AF_XDP
> path to the new API.
>
> Patch 6 to 11 migrates the existing zero-copy drivers to the new API.
>
> Patch 12 removes the MEM_TYPE_ZERO_COPY memory type, and the "handle"
> member of struct xdp_buff.
>
> Patch 13 simplifies the xdp_return_{frame,frame_rx_napi,buff}
> functions.
>
> Patch 14 is a performance patch, where some functions are inlined.
>
> Finally, patch 15 updates the MAINTAINERS file to correctly mirror the
> new file layout.
>
> Note that this series removes the "handle" member from struct
> xdp_buff, which reduces the xdp_buff size.
>
> After this series, the diff stat of drivers/net/ is:
>   27 files changed, 419 insertions(+), 1288 deletions(-)
>
> This series is a first step of simplifying the driver side of
> AF_XDP. I think more of the AF_XDP logic can be moved from the drivers
> to the AF_XDP core, e.g. the "need wakeup" set/clear functionality.
>
> Statistics when allocation fails can now be added to the socket
> statistics via the XDP_STATISTICS getsockopt(). This will be added in
> a follow up series.
>
>
> Performance
> ===========
>
> As a nice side effect, performance is up a bit as well.
>
>   * i40e: 3% higher pps for rxdrop, zero-copy, aligned and unaligned
>     (40 GbE, 64B packets).
>   * mlx5: RX +0.8 Mpps, TX +0.4 Mpps
>
>
> Changelog
> =========
>
> v4->v5:
>   * Fix various kdoc and GCC warnings (W=1). (Jakub)

Applied to bpf-next. Thanks!