[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2773eabb-68ac-faec-a629-6c2d8b7a1582@mellanox.com>
Date: Thu, 13 Jun 2019 14:01:45 +0000
From: Maxim Mikityanskiy <maximmi@...lanox.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
CC: 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 00/17] AF_XDP infrastructure improvements and
mlx5e support
On 2019-06-12 23:48, Jakub Kicinski wrote:
> On Wed, 12 Jun 2019 15:56:33 +0000, Maxim Mikityanskiy wrote:
>> UAPI is not changed, XSK RX queues are exposed to the kernel. The lower
>> half of the available amount of RX queues are regular queues, and the
>> upper half are XSK RX queues.
>
> If I have 32 queues enabled on the NIC
Let's say we have 32 combined channels. In this case RX queues 0..31 are
regular ones, and 32..63 are XSK-ZC-enabled.
> and I install AF_XDP socket on
> queue 10
It'll trigger the compatibility mode of AF_XDP (without zero copy). You
should use queue 42, which is in the 32..63 set.
> , does the NIC now have 64 RQs, but only first 32 are in the
> normal RSS map?
Only the regular 0..31 RX queues are part of RSS.
>
>> The patch "xsk: Extend channels to support combined XSK/non-XSK
>> traffic" was dropped. The final patch was reworked accordingly.
>
> The final patches has 2k LoC, kind of hard to digest. You can also
> post the clean up patches separately, no need for large series here.
>
I used to have the final patch as three patches (add XSK stubs, add RX
support and add TX support), but I prefer not to have this separation,
because it doesn't look right to add empty stub functions with /* TODO:
implement */ comments in one patch and to add the implementations
immediately in the next patch.
Thanks for reviewing!
Max
Powered by blists - more mailing lists