Re: [PATCH 0/8] Introduce fwctl subystem

[David Ahern <dsahern@kernel.org>]

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.