On 6/7/24 12:48 AM, Jiri Pirko wrote: >> 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. > You meant financial reasons, not political. The dominant player in switches has zero interest in switchdev, zero interest in open sourcing their SDK. Nothing has changed on that front in the 9 years of switchdev's existence and no amount of 'NO' by maintainers is ever going to pressure said vendor to do that. Mellanox offers both with the Spectrum line and should have a pretty good understanding of how many customers deploy with the SDK vs switchdev. Why is that? There are those who think in logical, simple designs (switchdev), and those who prefer complex, all userspace designs with ping-ponging messages across processes (sonic). The latter uses all kinds of what I call silly rationalizations from userspace allows more flexibility, to dealing with the the kernel is too rigid, or getting changes in is too hard, or my favorite - Linux does not scale. The bottom line is that the SDK model is not going away. Period. The networking stack has accepted kernel bypass compromises (xdp, xdp sockets, OVS, a lot of the ebpf hooks, ... just examples) with the rationale that more is brought into the Linux way. fwctl is a similar effort - an attempt at bringing more into an open source driver and tooling.
