Re: [RFC net-next 0/4] devlink: Add boot-time defaults

[Jakub Kicinski]

On Mon, 11 May 2026 10:42:56 +0200 Jiri Pirko wrote:
> Sun, May 10, 2026 at 06:37:32PM +0200, kuba@xxxxxxxxxx wrote:
> >On Sat, 9 May 2026 09:01:23 +0200 Jiri Pirko wrote:  
> >> Sat, May 09, 2026 at 02:52:13AM +0200, kuba@xxxxxxxxxx wrote:  
> >> As "a non-SR-IOV user", what extra representors you talk about? When you
> >> have pfs only, you don't have anything extra. Just 1 netdev per-pf, one
> >> devlink port per-pf. What's extra about it? When you don't have VFs/SFs.
> >> Everyhing is the same:  
> >
> >Some devices have separate uplink ports and PF representors.
> >As I said, what you're proposing isn't going to work for all drivers.  
> 
> Well, the point is, mlx5 appears to the the one needing this, not other
> drivers. What I'm trying to point at, mlx5 should not need this.
> It makes things compicated, adding a ugly knob for no good reason.
> Legacy/switchdev mode, in both, the non-sriov/eswitch user should not
> see different behaviour. The mode is an eswitch attribute.
> 
>    devlink dev eswitch set - sets devlink device eswitch attributes
>        mode { legacy | switchdev }
>               Set eswitch mode
> 
>               legacy - Legacy SRIOV
> 
>               switchdev - SRIOV switchdev offloads
> 
> 
> Briefly looking over other drivers, looks like ice, bnxt, octeon, sfc,
> there is no new entity created in case of switching to switchdev mode.
> The only driver that creates separate pf entities seems to be nfp,
> but the mode seems to be determined by the app being run (loaded
> firmware).
> 
> Am I missing something?

Hm. Okay, I wasn't aware that mlx5 was the only driver that did
heavy-duty reinit for switching modes.

> >> I look at it from the perspective that from some CX generation,
> >> switchdev mode should be default. So that is a device-based decision.
> >> I believe as such it can optionally be permanenty configured (nv config)
> >> on older device. Why not?  
> >
> >Feels a bit arbitrary and won't cover all cases. The question should be  
> 
> What cases it does not cover? I don't follow.

Other FW and HW versions. People are still using EOL devices (CX4/CX5),
IIUC the nvmem config path would require FW upgrade.

> >why you are nacking a more reasonable solution. Keeping Linux config in
> >Linux params.  
> 
> What's reasonable about adding basically a module option (kernel cmdline
> is pretty much the same) for no reason?

The initial patch as posted added this to a mlx5-specific module param.
If we need a module param IMO generic one is much better.
Doesn't matter if other drivers take no time to reinit into switchdev
mode, having to switch mlx5 with a module param and all the rest in
runtime is not the best user experience?