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

[Parav Pandit]

> From: Jiri Pirko <jiri@xxxxxxxxxxx>
> Sent: 12 May 2026 02:16 PM
> 
> Mon, May 11, 2026 at 08:21:37PM +0200, parav@xxxxxxxxxx wrote:
> >
> >> From: Mark Bloch <mbloch@xxxxxxxxxx>
> >> Sent: 10 May 2026 06:02 PM
> >>
> >
> >[..]
> >
> >> > 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?
> >>
> >Because sometimes switchdev_inactive is needed and sometimes not.
> >Such knob is not device decision.
> 
> That is what I would call corner case. In that, user can use userspace
> configuration to change the mode in runtime.
> 
Corner vs common depends on users one talks to. :)
If fw has switchdev(active) as default, and then 
And user needs to run switchdev_inactive, it will actually break their switching applications.

So, one needs to invent switchdev_inactive in the FW.

Jakub's suggestion in this RFC is covering both the scenarios uniformly without above problems.
Single uapi for all the cases, so looks good to me.

Moreover, do not understand how alternative solves such problems.
i.e. user is unable to configure the fw because driver is not yet loaded/up.

> 
> >If it is placed in the device, orchestration needs to yet use additional vendor tool to configure in the device.
> >And that theoretical tool cannot even run yet because driver is not yet loaded.
> >
> >That sort of defeats the purpose.
> >
> >> This is a deployment policy decision, not a permanent property of the card.
> >+1
> >
> >> The same adapter can be used in a regular host/RDMA setup or in a
> >> switchdev/offload setup. If we store this in NVM, that Linux switchdev policy
> >> follows the device across hosts, kernels and use cases, and can surprise the
> >> next deployment that just expects a normal NIC.
> >>
> >> I'll send another RFC v2 with support limited to:
> >> devlink=[...]:esw:mode:{ switchdev | switchdev_inactive | legacy }
> >> and let's see where we land with that.
> >>
> >This looks elegant to me as well covering all eswitch modes and still sw is in control.