On 03/05/2026 4:41, Jakub Kicinski wrote:

On Sat, 2 May 2026 23:08:43 +0300 Mark Bloch wrote:

quoted

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.

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.

BTW looks like issues Sashiko/Claude finds are slightly different,
let me send them out.

Right, we saw that as well. That is expected, since the
comments depend on the model being used, and can even differ between
runs of the same model.

I saw on patchwork that Sashiko/NIPA run had timed out, so I did not
have those comments when I replied. I’ll go over the additional
comments you've sent, thanks!

Mark