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

[Jiri Pirko <jiri@resnulli.us>]

Tue, May 12, 2026 at 03:48:32PM CEST, parav@nvidia.com wrote:
>
>> From: Jiri Pirko <jiri@resnulli.us>
>> Sent: 12 May 2026 02:16 PM
>> 
>> Mon, May 11, 2026 at 08:21:37PM +0200, parav@nvidia.com wrote:
>> >
>> >> From: Mark Bloch <mbloch@nvidia.com>
>> >> 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.

Can you describe the actutal breakage please?

>
>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.

See my other reply in this thread. I don't think there is a need to
configure anything in FW. If we fix the behaviour in switchdev mode for
non-sriov user and change the default, no fw knob needed. What am I
missing?


>
>> 
>> >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.