Re: pull-request: mlx5-next 2023-01-24 V2

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 3 Feb 2023 16:47:26 -0800 Saeed Mahameed wrote:
> On 03 Feb 13:14, Jakub Kicinski wrote:
> >I believe Paolo is planning to look next week. No idea why the patch
> >got marked as Accepted 🤷️
> >
> >On Fri, 3 Feb 2023 12:05:56 -0800 Saeed Mahameed wrote:  
> >> I don't agree, RDMA isn't proprietary, and I wish not to go into this
> >> political discussion, as this series isn't the right place for that.  
> >
> >I don't think it's a political discussion. Or at least not in the sense
> >of hidden agendas because our agendas aren't hidden. I'm a maintainer
> >of an open source networking stack, you're working for a vendor who
> >wants to sell their own networking stack.
> 
> we don't own any networking stack.. yes we do work on multiple opesource
> fronts and projects, but how is that related to this patchset ? 
> For the sake of this patchset, this purely mlx5 device management, and
> yes for RoCE traffic, RoCE is RDMA spec and standard and an open source
> mainstream kernel stack.

My memory is that Leon proposed IPsec offload, I said "you're doing
this for RDMA", he said "no we will also need this for TC redirect",
I said "if you implement TC redirect that's a legit use of netdev APIs".

And now RDMA integration is coming, and no TC in sight.

I think it's reasonable for me to feel mislead.

> >I don't think we can expect Linus to take a hard stand on this, but
> >do not expect us to lend you our APIs and help you sell your product.
> >
> >Saying that RDMA/RoCE is not proprietary because there is a "standard"
> >is like saying that Windows is an open source operating system because
> >it supports POSIX.
> 
> Apples and oranges, really :) .. 
> 
> Sorry but I have to disagree, the difference here is that the spec
> is open and the stack is in the mainstream linux, and there are at least
> 10 active vendors currently contributing to rdma with open source driver
> and open source user space, and there is pure software RoCE
> implementation for the paranoid who don't trust hw vendors, oh and it uses
> netdev APIs, should that be also forbidden ??

I don't want to be having theoretical discussions.
In theory there could exist a fully open RoCE implementation which
inter-operates with all other implementations perfectly. Agreed.

> What you're really saying here is that no vendor is allowed to do any
> offload or acceleration ..

IDK where you got that form, and it's obviously counter factual.
If I was nacking all offloads, I've have nacked the "full" IPsec
offload and we wouldn't be having this conversation at all.