[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190614184052.7de9471b@cakuba.netronome.com>
Date: Fri, 14 Jun 2019 18:40:52 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Maxim Mikityanskiy <maximmi@...lanox.com>
Cc: Jesper Dangaard Brouer <brouer@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Björn Töpel
<bjorn.topel@...el.com>,
Magnus Karlsson <magnus.karlsson@...el.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Saeed Mahameed <saeedm@...lanox.com>,
Jonathan Lemon <bsd@...com>,
Tariq Toukan <tariqt@...lanox.com>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Maciej Fijalkowski <maciejromanfijalkowski@...il.com>
Subject: Re: [PATCH bpf-next v4 05/17] xsk: Change the default frame size to
4096 and allow controlling it
On Fri, 14 Jun 2019 13:25:28 +0000, Maxim Mikityanskiy wrote:
> On 2019-06-13 20:29, Jakub Kicinski wrote:
> > On Thu, 13 Jun 2019 14:01:39 +0000, Maxim Mikityanskiy wrote:
> >
> > Yes, okay, I get that. But I still don't know what's the exact use you
> > have for AF_XDP buffers being 4k.. Could you point us in the code to
> > the place which relies on all buffers being 4k in any XDP scenario?
Okay, I still don't get it, but that's for explaining :) Perhaps it
will become clearer when you resping with patch 17 split into
reviewable chunks :)
> 1. An XDP program is set on all queues, so to support non-4k AF_XDP
> frames, we would also need to support multiple-packet-per-page XDP for
> regular queues.
Mm.. do you have some materials of how the mlx5 DMA/RX works? I'd think
that if you do single packet per buffer as long as all packets are
guaranteed to fit in the buffer (based on MRU) the HW shouldn't care
what the size of the buffer is.
> 2. Page allocation in mlx5e perfectly fits page-sized XDP frames. Some
> examples in the code are:
>
> 2.1. mlx5e_free_rx_mpwqe calls a generic mlx5e_page_release to release
> the pages of a MPWQE (multi-packet work queue element), which is
> implemented as xsk_umem_fq_reuse for the case of XSK. We avoid extra
> overhead by using the fact that packet == page.
>
> 2.2. mlx5e_free_xdpsq_desc performs cleanup after XDP transmits. In case
> of XDP_TX, we can free/recycle the pages without having a refcount
> overhead, by using the fact that packet == page.
Powered by blists - more mailing lists