On Fri, Feb 03, 2023 at 01:14:56PM -0800, 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. Wow, come down to earth a bit here, jeeze. You are the maintainer of an open source subcomponent in Linux I am the maintainer of an open source subcomponent in Linux Gosh, they have some technological differences, but hey so does netdev vs NVMe too - are you also upset that NVMe is less pure than netdev because all the "crucial" flash management is proprietary? Or suggest that we should rip out all the AWS, GCP and HyperV drivers because the hypervisor that creates them is closed source? Heck, we both have quite interesting employers that bring their own bias's and echo chambers. Dave drew his line for netdev long ago, and I really respect that choice and his convictions. But don't act like it is "better" or somehow "more Linusy" than every other subsystem in the kernel. > 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. I think Linus has taken a stand. He is working on *Linux* not GNU Hurd. The difference is Linux welcomes all HW and all devices. Bring your open source kernel code and open source user space and you are welcome here. Sure the community has lots of different opinions, and there is a definite group that leans in direction of wanting more open-ness outside the kernel too, but overall Linus has kept consistent and has not refused participation of HW on stricter ideological grounds. "You are welcome here" is exactly why Linux dominates the industry and GNU Hurd is a footnote. "help you sell your product" when talking about a fellow open source subsystem is an insulting line that has no business on these mailing lists. > 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. That is a very creative definition of proprietary. If you said "open source software to operate standards based fixed function HW engines" you'd have a lot more accuracy and credibility, but it doesn't sound as scary when you say it like that, does it? RDMA is a alot more open than an NVMe drive, for instance. > My objectives for netdev are: > - give users vendor independence > - give developers the ability to innovate > > I have not seen an RDMA implementation which could deliver on either. > Merging this code is contrary to my objectives for the project. The things we do in other parts of the kernel in no way degrade these activities for netdev. RDMA mirroring the netdev configurations is irrelevant to the continued technical development of netdev, or its ability to innovate. We've never once said "you can't do that" to netdev because of something RDMA is doing. I've been strict about that, rdma is on the side of netdev and does not shackle netdev. You've made it very clear you don't like the RDMA technology, but you have no right to try and use your position as a kernel maintainer to try and kill it by refusing PRs to shared driver code. Let's try to all get along. > > To summarize, mlx5_core is doing RoCE traffic processing and directs it to > > mlx5_ib driver (a standard rdma stack), in this series we add RoCE ipsec > > traffic processing as we do for all other RoCE traffic. > > I already said it. If you wanted to configure IPsec for RoCE you should > have added an API in the RDMA subsystem. Did that years ago. https://github.com/linux-rdma/rdma-core/blob/master/providers/mlx5/man/mlx5dv_flow_action_esp.3.md HW accelerated IPSEC has been in RDMA and DPDK for a long time now, the mlx5 team is trying to catch up netdev because NVIDIA has customers interested in using netdev with ipsec and would like to get best performance from their HW. We always try to do a complete job and ensure that RDMA's use of the shared IP/port and netdev use of the shared IP/port are as consistent as we can get - and now that it is technically trivial for mlx5 to run the RDMA IP traffic inside the HW that matches the netdev flows we will do that too. It is really paranoid to think we somehow did all the netdev enablement just to get something in RDMA. Sorry, there is no incredible irreplaceable value there. The netdev stuff was a lot of difficult work and was very much done to run traffic originating in netdev. Real customers have mixed workloads, and I think that's great. You should try looking outside the bubble of your peculiar hyperscaler employer someday and see what the rest of the industry is doing. There is a reason every high speed NIC has a RDMA offering now, a reason every major cloud has some kind of RDMA based networking offering and a reason I've been merging a couple new RDMA drivers every year. None of that activity takes away from netdev - it is not a zero sum game. Even more importantly, for Linux, my multivendor open source community is every bit as legitimate as yours. I appreciate your political leanings, and your deep concern for netdev. But I have no idea why you care what RDMA does, and reject this absurd notion that the IP address, or APIs inside our shared Linux kernel are somehow "yours" alone to decide how and when they are used. Jason
