netdev - Re: [PATCH bpf-next v5 00/15] Introduce AF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 May 2020 17:37:43 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Björn Töpel <bjorn.topel@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>,
        "Karlsson, Magnus" <magnus.karlsson@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Maxim Mikityanskiy <maximmi@...lanox.com>,
        "Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>,
        Björn Töpel <bjorn.topel@...el.com>
Subject: Re: [PATCH bpf-next v5 00/15] Introduce AF_XDP buffer allocation API

On Wed, May 20, 2020 at 12:21 PM Björn Töpel <bjorn.topel@...il.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!