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.
