From: Jiri Pirko <jiri@resnulli•us>
To: Parav Pandit <parav@nvidia•com>
Cc: Mark Bloch <mbloch@nvidia•com>, Jakub Kicinski <kuba@kernel•org>,
Eric Dumazet <edumazet@google•com>,
Paolo Abeni <pabeni@redhat•com>,
Andrew Lunn <andrew+netdev@lunn•ch>,
"David S. Miller" <davem@davemloft•net>,
Jonathan Corbet <corbet@lwn•net>,
Shuah Khan <skhan@linuxfoundation•org>,
Simon Horman <horms@kernel•org>,
Saeed Mahameed <saeedm@nvidia•com>,
Leon Romanovsky <leon@kernel•org>,
Tariq Toukan <tariqt@nvidia•com>,
Andrew Morton <akpm@linux-foundation•org>,
"Borislav Petkov (AMD)" <bp@alien8•de>,
Randy Dunlap <rdunlap@infradead•org>,
Dave Hansen <dave.hansen@linux•intel.com>,
Christian Brauner <brauner@kernel•org>,
Petr Mladek <pmladek@suse•com>,
"Peter Zijlstra (Intel)" <peterz@infradead•org>,
Thomas Gleixner <tglx@kernel•org>,
Pawan Gupta <pawan.kumar.gupta@linux•intel.com>,
Dapeng Mi <dapeng1.mi@linux•intel.com>,
Kees Cook <kees@kernel•org>, Marco Elver <elver@google•com>,
Eric Biggers <ebiggers@kernel•org>,
"NBU-Contact-Li Rongqing (EXTERNAL)" <lirongqing@baidu•com>,
"Paul E. McKenney" <paulmck@kernel•org>,
"linux-doc@vger•kernel.org" <linux-doc@vger•kernel.org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"linux-rdma@vger•kernel.org" <linux-rdma@vger•kernel.org>
Subject: Re: [RFC net-next 0/4] devlink: Add boot-time defaults
Date: Tue, 12 May 2026 10:45:30 +0200 [thread overview]
Message-ID: <agLoeZtsSizR-R24@FV6GYCPJ69> (raw)
In-Reply-To: <SJ0PR12MB68068C50EE9776A3D9060635DC382@SJ0PR12MB6806.namprd12.prod.outlook.com>
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.
>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.
next prev parent reply other threads:[~2026-05-12 8:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 12:37 [RFC net-next 0/4] devlink: Add boot-time defaults Mark Bloch
2026-05-06 12:37 ` [RFC net-next 1/4] devlink: Add infrastructure for " Mark Bloch
2026-05-06 12:37 ` [RFC net-next 2/4] devlink: Add eswitch mode boot default Mark Bloch
2026-05-06 12:37 ` [RFC net-next 3/4] devlink: Add runtime parameter boot defaults Mark Bloch
2026-05-06 12:37 ` [RFC net-next 4/4] net/mlx5: Apply devlink boot defaults during init Mark Bloch
2026-05-06 15:22 ` [RFC net-next 0/4] devlink: Add boot-time defaults Jiri Pirko
2026-05-06 17:35 ` Mark Bloch
2026-05-07 11:03 ` Jiri Pirko
2026-05-08 17:59 ` Mark Bloch
2026-05-08 18:07 ` Jiri Pirko
2026-05-09 0:52 ` Jakub Kicinski
2026-05-09 7:01 ` Jiri Pirko
2026-05-10 12:31 ` Mark Bloch
2026-05-11 8:07 ` Jiri Pirko
2026-05-11 18:21 ` Parav Pandit
2026-05-12 8:45 ` Jiri Pirko [this message]
2026-05-12 13:48 ` Parav Pandit
2026-05-12 14:07 ` Jiri Pirko
2026-05-12 15:25 ` Parav Pandit
2026-05-12 18:35 ` Jiri Pirko
2026-05-13 5:53 ` Mark Bloch
2026-05-13 11:11 ` Jiri Pirko
2026-05-14 12:34 ` Mark Bloch
2026-05-10 16:37 ` Jakub Kicinski
2026-05-11 8:42 ` Jiri Pirko
2026-05-11 23:41 ` Jakub Kicinski
2026-05-12 8:42 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agLoeZtsSizR-R24@FV6GYCPJ69 \
--to=jiri@resnulli$(echo .)us \
--cc=akpm@linux-foundation$(echo .)org \
--cc=andrew+netdev@lunn$(echo .)ch \
--cc=bp@alien8$(echo .)de \
--cc=brauner@kernel$(echo .)org \
--cc=corbet@lwn$(echo .)net \
--cc=dapeng1.mi@linux$(echo .)intel.com \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=davem@davemloft$(echo .)net \
--cc=ebiggers@kernel$(echo .)org \
--cc=edumazet@google$(echo .)com \
--cc=elver@google$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=kees@kernel$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=leon@kernel$(echo .)org \
--cc=linux-doc@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-rdma@vger$(echo .)kernel.org \
--cc=lirongqing@baidu$(echo .)com \
--cc=mbloch@nvidia$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=parav@nvidia$(echo .)com \
--cc=paulmck@kernel$(echo .)org \
--cc=pawan.kumar.gupta@linux$(echo .)intel.com \
--cc=peterz@infradead$(echo .)org \
--cc=pmladek@suse$(echo .)com \
--cc=rdunlap@infradead$(echo .)org \
--cc=saeedm@nvidia$(echo .)com \
--cc=skhan@linuxfoundation$(echo .)org \
--cc=tariqt@nvidia$(echo .)com \
--cc=tglx@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox