Thu, Jun 06, 2024 at 07:47:20PM CEST, dsahern@xxxxxxxxxx wrote: >On 6/6/24 9:05 AM, Jakub Kicinski wrote: >> On Thu, 6 Jun 2024 11:48:18 -0300 Jason Gunthorpe wrote: >>>> An argument can be made that given somewhat mixed switchdev experience >>>> we should just stay out of the way and let that happen. But just make >>>> that argument then, instead of pretending the use of this API will be >>>> limited to custom very vendor specific things. >>> >>> Huh? >> >> I'm sorry, David as been working in netdev for a long time. > >And I will continue working on Linux networking stack (netdev) while I >also work with the IB S/W stack, fwctl, and any other part of Linux >relevant to my job. I am not going to pick a silo (and should not be >required to). > >> I have a tendency to address the person I'm replying to, >> assuming their level of understanding of the problem space. >> Which makes it harder to understand for bystanders. >> >>> At least mlx5 already has a very robust userspace competition to >>> switchdev using RDMA APIs, available in DPDK. This is long since been >>> done and is widely deployed. >> >> Yeah, we had this discussion multiple times > >The switchdev / sonic comparison came to mind as well during this >thread. The existence of a kernel way (switchdev) has not stopped sonic >(userspace SDK) from gaining traction. In some cases the SDK is required Is this discussion technical or policital? I'm asking because it makes huge difference. There is no technical reason why sonic does not use proper in-kernel solution from what I see Yes, they chose technically the wrong way, a shortcut, requiring kernel bypass. Honestly for reasons that are beyond my understanding :/ >for device features that do not have a kernel uapi or vendors refuse to >offer a kernel way, so it is the only option. Policical reasons. > >The bottom line to me is that these hardline, dogmatic approaches - >resisting the recognition of reality - is only harming users. There is a >middle ground, open source drivers and tools that offer more flexibility. >
