On Fri, 2019-05-24 at 12:18 +0200, Björn Töpel wrote:

On 2019-05-24 11:35, Maxim Mikityanskiy wrote:

quoted

This series contains improvements to the AF_XDP kernel
infrastructure
and AF_XDP support in mlx5e. The infrastructure improvements are
required for mlx5e, but also some of them benefit to all drivers,
and
some can be useful for other drivers that want to implement AF_XDP.

[...]

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.

Hi Bjorn and Magnus,

It is not clear to me why you don't like this approach, if anything,
this approach is addressing many concerns you raised about current
limited approach of re-using/"stealing" only regular RX rings for xsk
traffic !

for instance 
1) xsk ring now has a unique id. (wasn't this the plan from the
beginning ?) 
2) No RSS issues, only explicit steering rules got the the newly
created isolated xsk ring, default RSS is not affected regular RX rings
are still intact.
3) the new scheme is flexible and will allow as much xsk sockets as
needed, and can co-exist with regular rings. 
4) We want to have a solution that will replace DPDK, having such
limitations of a limited number of RX rings and stealing from regular
rings, is really not a worthy design, just because some drivers do not
want to deal or don't know how to deal with creating dedicated
resources.
5) i think it is wrong to compare xsk rings with regular rings, xsk
rings are actually just a a device context that redirects traffic to a
special buffer space, there is no real memory buffers model behind it,
other than the rx/tx descriptors. (memory model is handled outside the
driver).
6) mlx5 is designed and optimized for such use cases (dedicated/unique
rx/tx rings for XDP), limiting us to current AF_XDP limitation without
allowing us to improve the AF_XDP design is really not fair.

the way i see it, this new extension is actually a generalization to
allow for more drivers support and AF_XDP flexibility.

if you have different ideas on how to implement the new design, please
provide your feedback and we will be more than happy to improve the
current implementation, but requesting to drop it, i think is not a
fair request.

Side note: Our task is to provide a scalable and flexible in-kernel XDP
solution so we can offer a valid replacement for DPDK and userspace
only solutions, I think we need to have a scheme where we allow an
unlimited number of xsk sockets/rings with full flow
separation/isolation between different user sockets/apps, the driver/hw
resources are really very cheap (as there is no buffer management) much
cheaper than allocating a full blown regular socket buffers.

Thanks,
Saeed.

Thanks,
Björn

[1] 
https://lore.kernel.org/bpf/CAJ8uoz2UHk+5xPwz-STM9gkQZdm7r_=jsgaB0nF+mHgch=axPg@mail.gmail.com/ (local)