Re: [PATCH net-next V2 7/7] net/mlx5: Add profile to auto-enable switchdev mode at device init

[Jakub Kicinski <kuba@kernel.org>]

On Sun, 3 May 2026 10:51:06 +0300 Mark Bloch wrote:
> On 03/05/2026 4:41, Jakub Kicinski wrote:
> > On Sat, 2 May 2026 23:08:43 +0300 Mark Bloch wrote:  
> >> Before I respin for the unrelated MR_CACHE cleanup, I’d like to confirm
> >> whether the opt-in profile approach is acceptable at all. Regardless
> >> of this last patch, the first 6 patches fix real representor/LAG locking
> >> issues and are needed independently, so I’d like to keep those moving toward
> >> acceptance as soon as possible.  
> > 
> > For probe-time config module param is probably our only option.
> > I'd obviously prefer to have a devlink-level knob for this, instead 
> > of a mlx5 specific one. Can we come up with some format that'd apply
> > more broadly? devlink=[$bfd:]flag1 ? so devlink=[$bdf:]switchdev-mode ?  
> 
> I’m not convinced this is really a generic devlink knob problem.

I'm surprised you say that. Anyone using switchdev mode could benefit.
Having the probe in one mode and switch adds to boot time. Whether it's
a DPU or not is quite secondary.

Unless there's another deeper reason which makes the DPU incapable of
running in the non-switchdev mode. But not sure that squares with the
code you posted AFAICT.

> A device should probe in its selected/default configuration. For DPU
> deployments switchdev is the expected operating mode. mlx5 just made the
> wrong default choice historically, and this profile is a way to move away
> from that without forcing it on everyone at once. I expect/hope to move
> quickly from this flag to simply making switchdev the driver default for
> all DPU configs.
> 
> A generic cmdline format also gets complicated quickly: vendor-specific
> flags, ordering/dependencies between flags, hotplug timing, and whether a
> BDF rule should apply when a device is passed into a VM after boot.
> Userspace scripts are probably better for that kind of policy because
> they can carry real site specific logic.
> 
> I’ll drop this last patch from the series for now so the representor/LAG
> locking fixes can move independently and we can continue the default
> switchdev discussion separately. I can always submit that as a standalone
> patch later in the cycle if needed.

SG