BPF Archive on lore.kernel.org
 help / color / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: "Björn Töpel" <bjorn.topel@gmail.com>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Jesper Dangaard Brouer" <hawk@kernel.org>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"Network Development" <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	"Karlsson, Magnus" <magnus.karlsson@intel.com>,
	"Jonathan Lemon" <jonathan.lemon@gmail.com>,
	"Jeff Kirsher" <jeffrey.t.kirsher@intel.com>,
	"Maxim Mikityanskiy" <maximmi@mellanox.com>,
	"Fijalkowski, Maciej" <maciej.fijalkowski@intel.com>,
	"Björn Töpel" <bjorn.topel@intel.com>
Subject: Re: [PATCH bpf-next v5 00/15] Introduce AF_XDP buffer allocation API
Date: Thu, 21 May 2020 17:37:43 -0700
Message-ID: <CAADnVQJTPUNUmVvSmQMdbPeNU90gS69_Y7gWBKh+3masJX_xkQ@mail.gmail.com> (raw)
In-Reply-To: <20200520192103.355233-1-bjorn.topel@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!

  parent reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 19:20 Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 01/15] xsk: fix xsk_umem_xdp_frame_sz() Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 02/15] xsk: move xskmap.c to net/xdp/ Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 03/15] xsk: move driver interface to xdp_sock_drv.h Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 04/15] xsk: move defines only used by AF_XDP internals to xsk.h Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 05/15] xsk: introduce AF_XDP buffer allocation API Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 06/15] i40e: refactor rx_bi accesses Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 07/15] i40e: separate kernel allocated rx_bi rings from AF_XDP rings Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 08/15] i40e, xsk: migrate to new MEM_TYPE_XSK_BUFF_POOL Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 09/15] ice, " Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 10/15] ixgbe, " Björn Töpel
2020-05-20 19:20 ` [PATCH bpf-next v5 11/15] mlx5, " Björn Töpel
2020-05-20 19:21 ` [PATCH bpf-next v5 12/15] xsk: remove MEM_TYPE_ZERO_COPY and corresponding code Björn Töpel
2020-05-20 19:21 ` [PATCH bpf-next v5 13/15] xdp: simplify xdp_return_{frame,frame_rx_napi,buff} Björn Töpel
2020-05-20 19:21 ` [PATCH bpf-next v5 14/15] xsk: explicitly inline functions and move definitions Björn Töpel
2020-05-20 19:21 ` [PATCH bpf-next v5 15/15] MAINTAINERS, xsk: update AF_XDP section after moves/adds Björn Töpel
2020-05-22  0:37 ` Alexei Starovoitov [this message]
2020-05-22  3:37 ` [PATCH bpf-next v5 00/15] Introduce AF_XDP buffer allocation API Kirsher, Jeffrey T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAADnVQJTPUNUmVvSmQMdbPeNU90gS69_Y7gWBKh+3masJX_xkQ@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@gmail.com \
    --cc=bjorn.topel@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=hawk@kernel.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=maximmi@mellanox.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git