[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230203175739.1fef3a24@kernel.org>
Date: Fri, 3 Feb 2023 17:57:39 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Saeed Mahameed <saeed@...nel.org>
Cc: Leon Romanovsky <leon@...nel.org>,
Jason Gunthorpe <jgg@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Saeed Mahameed <saeedm@...dia.com>, linux-rdma@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: pull-request: mlx5-next 2023-01-24 V2
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.
Powered by blists - more mailing lists