All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: "Björn Töpel" <bjorn.topel@intel.com>
Cc: Maxim Mikityanskiy <maximmi@mellanox.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Magnus Karlsson <magnus.karlsson@intel.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Saeed Mahameed <saeedm@mellanox.com>, Jonathan Lemon <bsd@fb.com>,
	Tariq Toukan <tariqt@mellanox.com>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	Maciej Fijalkowski <maciejromanfijalkowski@gmail.com>
Subject: Re: [PATCH bpf-next v3 00/16] AF_XDP infrastructure improvements and mlx5e support
Date: Fri, 24 May 2019 10:58:28 -0700	[thread overview]
Message-ID: <20190524105828.665facc0@cakuba.netronome.com> (raw)
In-Reply-To: <8b0450c2-ad5e-ecaa-9958-df4da1dd6456@intel.com>

On Fri, 24 May 2019 12:18:32 +0200, Björn Töpel wrote:
> Maxim, this doesn't address the uapi concern we had on your v2.
> Please refer to Magnus' comment here [1].
> 
> Please educate me why you cannot publish AF_XDP without the uapi change?
> It's an extension, right? If so, then existing XDP/AF_XDP program can
> use Mellanox ZC without your addition? It's great that Mellanox has a ZC
> capable driver, but the uapi change is a NAK.
> 
> To reiterate; We'd like to get the queue setup/steering for AF_XDP
> correct. I, and Magnus, dislike this approach. It requires a more
> complicated XDP program, and is hard for regular users to understand.

+1

  reply	other threads:[~2019-05-24 17:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24  9:35 [PATCH bpf-next v3 00/16] AF_XDP infrastructure improvements and mlx5e support Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 01/16] xsk: Add API to check for available entries in FQ Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 02/16] xsk: Add getsockopt XDP_OPTIONS Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 03/16] libbpf: Support " Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 04/16] xsk: Extend channels to support combined XSK/non-XSK traffic Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 05/16] xsk: Change the default frame size to 4096 and allow controlling it Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 06/16] xsk: Return the whole xdp_desc from xsk_umem_consume_tx Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 07/16] net/mlx5e: Replace deprecated PCI_DMA_TODEVICE Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 08/16] net/mlx5e: Calculate linear RX frag size considering XSK Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 09/16] net/mlx5e: Allow ICO SQ to be used by multiple RQs Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 10/16] net/mlx5e: Refactor struct mlx5e_xdp_info Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 11/16] net/mlx5e: Share the XDP SQ for XDP_TX between RQs Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 12/16] net/mlx5e: XDP_TX from UMEM support Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 13/16] net/mlx5e: Consider XSK in XDP MTU limit calculation Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 14/16] net/mlx5e: Encapsulate open/close queues into a function Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 15/16] net/mlx5e: Move queue param structs to en/params.h Maxim Mikityanskiy
2019-05-24  9:35 ` [PATCH bpf-next v3 16/16] net/mlx5e: Add XSK support Maxim Mikityanskiy
2019-05-24 10:18 ` [PATCH bpf-next v3 00/16] AF_XDP infrastructure improvements and mlx5e support Björn Töpel
2019-05-24 17:58   ` Jakub Kicinski [this message]
2019-05-31 21:56   ` Saeed Mahameed
2019-06-03  8:27     ` Magnus Karlsson

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=20190524105828.665facc0@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=bsd@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kafai@fb.com \
    --cc=maciejromanfijalkowski@gmail.com \
    --cc=magnus.karlsson@intel.com \
    --cc=maximmi@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=songliubraving@fb.com \
    --cc=tariqt@mellanox.com \
    --cc=yhs@fb.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.