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

[Mark Bloch <mbloch@nvidia.com>]

On 12/05/2026 21:35, Jiri Pirko wrote:
> Tue, May 12, 2026 at 05:25:21PM CEST, parav@nvidia.com wrote:
>>
>>
>>> From: Jiri Pirko <jiri@resnulli.us>
>>> Sent: 12 May 2026 07:37 PM
>>>
>>> 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?
>>>
>> Driver default was switchdev so all the traffic is forwarded to the switch,
>> and user didn't have chance to setup the fdb rules.
>> So packets are dropped but user didn't expect the traffic to be forwarded.
> 
> User may switch mode to switchdev_inactive early on, before any of the
> representors are created. What's the issue then?

That is the ordering problem I am trying to solve.

On a DPU, the host PF cannot finish loading until the ECPF moves the eswitch to
switchdev/switchdev_inactive. So we need to do that transition during ECPF
driver init, as early as possible. Waiting for userspace means the host PF stays
blocked until userspace is up and has the right logic.

That is not always true in practice, the driver may be built in, loaded from an
initramfs, or the initramfs may simply not contain the devlink policy we need.

Also, after talking with Parav, my understanding is that we need to support both
switchdev and switchdev_inactive, since different customers want different boot
behavior. Once we do the transition, the host PF can load and may start sending
packets. At that point the initial mode already matters: in switchdev_inactive
packets are dropped until userspace programs the pipeline; in switchdev they may
reach the FDB before the pipeline is ready.

So I do not think an early userspace transition is equivalent here. The initial
mode needs to be known by the kernel before userspace runs, which is why I am
proposing the devlink= command line default.

Mark

> 
> 
>>
>> With this RFC, the device would start in the switchdev_inactive.
>> And user's goal is achieved.
>>
>>>>
>>>> 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 I understood your suggestion right, is it the devlinkd based solution?
> 
> The suggestion is to use "switchdev" as default with user configuration
> no matter if it is devlinkd or something else.
> 
> 
>>
>> If yes, then Mark explained that it has the issue of all drivers to be loaded, followed by user space to start.