[PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Parav Pandit]

When eswitch mode changes, notify such change to the
devlink monitoring process.

After this notification, a devlink monitoring process
can see following output:

$ devlink mon
[eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none encap-mode basic
[eswitch,get] pci/0000:06:00.0: mode legacy inline-mode none encap-mode basic

Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Parav Pandit <parav@nvidia.com>
---
changelog:
v0->v1:
- addressed comment from Jakub
- fixed cmd action from SET to GET to match the usual get command
  with other responses
---
 net/devlink/dev.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/net/devlink/dev.c b/net/devlink/dev.c
index 02602704bdea..d0d77e6689c2 100644
--- a/net/devlink/dev.c
+++ b/net/devlink/dev.c
@@ -701,6 +701,30 @@ int devlink_nl_eswitch_get_doit(struct sk_buff *skb, struct genl_info *info)
 	return genlmsg_reply(msg, info);
 }
 
+static void devlink_eswitch_notify(struct devlink *devlink)
+{
+	struct sk_buff *msg;
+	int err;
+
+	WARN_ON(!devl_is_registered(devlink));
+
+	if (!devlink_nl_notify_need(devlink))
+		return;
+
+	msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+	if (!msg)
+		return;
+
+	err = devlink_nl_eswitch_fill(msg, devlink, DEVLINK_CMD_ESWITCH_GET,
+				      0, 0, 0);
+	if (err) {
+		nlmsg_free(msg);
+		return;
+	}
+
+	devlink_nl_notify_send(devlink, msg);
+}
+
 int devlink_nl_eswitch_set_doit(struct sk_buff *skb, struct genl_info *info)
 {
 	struct devlink *devlink = info->user_ptr[0];
@@ -742,6 +766,7 @@ int devlink_nl_eswitch_set_doit(struct sk_buff *skb, struct genl_info *info)
 			return err;
 	}
 
+	devlink_eswitch_notify(devlink);
 	return 0;
 }
 
-- 
2.26.2

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jakub Kicinski]

On Wed, 19 Nov 2025 18:59:36 +0200 Parav Pandit wrote:
> When eswitch mode changes, notify such change to the
> devlink monitoring process.
> 
> After this notification, a devlink monitoring process
> can see following output:
> 
> $ devlink mon
> [eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none encap-mode basic
> [eswitch,get] pci/0000:06:00.0: mode legacy inline-mode none encap-mode basic
> 
> Reviewed-by: Jiri Pirko <jiri@nvidia.com>

Jiri, did you have a chance to re-review this or the tag is stale?
I have a slight preference for a new command ID here but if you
think GET is fine then so be it.

Is it possible to add this to the Netlink YAML spec? off the top of 
my head I think it's a "notification":

    -
      name: $name
      doc: $doc
      notify: eswitch-get

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jiri Pirko]

Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:
>On Wed, 19 Nov 2025 18:59:36 +0200 Parav Pandit wrote:
>> When eswitch mode changes, notify such change to the
>> devlink monitoring process.
>> 
>> After this notification, a devlink monitoring process
>> can see following output:
>> 
>> $ devlink mon
>> [eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none encap-mode basic
>> [eswitch,get] pci/0000:06:00.0: mode legacy inline-mode none encap-mode basic
>> 
>> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
>
>Jiri, did you have a chance to re-review this or the tag is stale?

Nope, I reviewed internally, that's why the tag was taken.


>I have a slight preference for a new command ID here but if you
>think GET is fine then so be it.

Well, For the rest of the notifications, we have NEW/DEL commands.
However in this case, as "eswitch" is somehow a subobject, there is no
NEW/DEL value defined. I'm fine with using GET for notifications for it.
I'm also okay with adding new ID, up to you.


>
>Is it possible to add this to the Netlink YAML spec? off the top of 
>my head I think it's a "notification":
>
>    -
>      name: $name
>      doc: $doc
>      notify: eswitch-get
>

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jakub Kicinski]

On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:
> Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:
> >On Wed, 19 Nov 2025 18:59:36 +0200 Parav Pandit wrote:  
> >> When eswitch mode changes, notify such change to the
> >> devlink monitoring process.
> >> 
> >> After this notification, a devlink monitoring process
> >> can see following output:
> >> 
> >> $ devlink mon
> >> [eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none encap-mode basic
> >> [eswitch,get] pci/0000:06:00.0: mode legacy inline-mode none encap-mode basic
> >> 
> >> Reviewed-by: Jiri Pirko <jiri@nvidia.com>  
> >
> >Jiri, did you have a chance to re-review this or the tag is stale?  
> 
> Nope, I reviewed internally, that's why the tag was taken.
> 
> >I have a slight preference for a new command ID here but if you
> >think GET is fine then so be it.  
> 
> Well, For the rest of the notifications, we have NEW/DEL commands.
> However in this case, as "eswitch" is somehow a subobject, there is no
> NEW/DEL value defined. I'm fine with using GET for notifications for it.
> I'm also okay with adding new ID, up to you.

Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
easier / possible to use the same socket for requests and notifications.
-- 
pw-bot: cr

RE: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Parav Pandit]

> From: Jakub Kicinski <kuba@kernel.org>
> Sent: 20 November 2025 08:22 PM
> 
> On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:
> > Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:
> > >On Wed, 19 Nov 2025 18:59:36 +0200 Parav Pandit wrote:
> > >> When eswitch mode changes, notify such change to the devlink
> > >> monitoring process.
> > >>
> > >> After this notification, a devlink monitoring process can see
> > >> following output:
> > >>
> > >> $ devlink mon
> > >> [eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none
> > >> encap-mode basic [eswitch,get] pci/0000:06:00.0: mode legacy
> > >> inline-mode none encap-mode basic
> > >>
> > >> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
> > >
> > >Jiri, did you have a chance to re-review this or the tag is stale?
> >
> > Nope, I reviewed internally, that's why the tag was taken.
> >
> > >I have a slight preference for a new command ID here but if you think
> > >GET is fine then so be it.
> >
> > Well, For the rest of the notifications, we have NEW/DEL commands.
> > However in this case, as "eswitch" is somehow a subobject, there is no
> > NEW/DEL value defined. I'm fine with using GET for notifications for it.
> > I'm also okay with adding new ID, up to you.
> 
> Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
> easier / possible to use the same socket for requests and notifications.

Ok. Will spin v2.
Thanks.

> --
> pw-bot: cr

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jiri Pirko]

Thu, Nov 20, 2025 at 03:52:23PM +0100, kuba@kernel.org wrote:
>On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:
>> Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:
>> >On Wed, 19 Nov 2025 18:59:36 +0200 Parav Pandit wrote:  
>> >> When eswitch mode changes, notify such change to the
>> >> devlink monitoring process.
>> >> 
>> >> After this notification, a devlink monitoring process
>> >> can see following output:
>> >> 
>> >> $ devlink mon
>> >> [eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none encap-mode basic
>> >> [eswitch,get] pci/0000:06:00.0: mode legacy inline-mode none encap-mode basic
>> >> 
>> >> Reviewed-by: Jiri Pirko <jiri@nvidia.com>  
>> >
>> >Jiri, did you have a chance to re-review this or the tag is stale?  
>> 
>> Nope, I reviewed internally, that's why the tag was taken.
>> 
>> >I have a slight preference for a new command ID here but if you
>> >think GET is fine then so be it.  
>> 
>> Well, For the rest of the notifications, we have NEW/DEL commands.
>> However in this case, as "eswitch" is somehow a subobject, there is no
>> NEW/DEL value defined. I'm fine with using GET for notifications for it.
>> I'm also okay with adding new ID, up to you.
>
>Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
>easier / possible to use the same socket for requests and notifications.

Well, you still can use the same socket with just ESWITCH_GET. Request
messages are going from userspace, notifications from kernel, there is
no mixup.

For the sake of consistency, shouldn't the name be ESWITCH_NEW?


>-- 
>pw-bot: cr

RE: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Parav Pandit]

> From: Jiri Pirko <jiri@resnulli.us>
> Sent: 21 November 2025 02:05 PM
> 
> Thu, Nov 20, 2025 at 03:52:23PM +0100, kuba@kernel.org wrote:
> >On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:
> >> Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:
> >> >On Wed, 19 Nov 2025 18:59:36 +0200 Parav Pandit wrote:
> >> >> When eswitch mode changes, notify such change to the devlink
> >> >> monitoring process.
> >> >>
> >> >> After this notification, a devlink monitoring process can see
> >> >> following output:
> >> >>
> >> >> $ devlink mon
> >> >> [eswitch,get] pci/0000:06:00.0: mode switchdev inline-mode none
> >> >> encap-mode basic [eswitch,get] pci/0000:06:00.0: mode legacy
> >> >> inline-mode none encap-mode basic
> >> >>
> >> >> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
> >> >
> >> >Jiri, did you have a chance to re-review this or the tag is stale?
> >>
> >> Nope, I reviewed internally, that's why the tag was taken.
> >>
> >> >I have a slight preference for a new command ID here but if you
> >> >think GET is fine then so be it.
> >>
> >> Well, For the rest of the notifications, we have NEW/DEL commands.
> >> However in this case, as "eswitch" is somehow a subobject, there is
> >> no NEW/DEL value defined. I'm fine with using GET for notifications for it.
> >> I'm also okay with adding new ID, up to you.
> >
> >Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
> >easier / possible to use the same socket for requests and notifications.
> 
> Well, you still can use the same socket with just ESWITCH_GET. Request
> messages are going from userspace, notifications from kernel, there is no
> mixup.
> 
> For the sake of consistency, shouldn't the name be ESWITCH_NEW?

It's the change happening in the eswitch: mode or attribute or something else tomorrow.
So it looks more like DPLL_CMD_DEVICE_CHANGE_NTF to me.

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jakub Kicinski]

On Fri, 21 Nov 2025 09:35:24 +0100 Jiri Pirko wrote:
> Thu, Nov 20, 2025 at 03:52:23PM +0100, kuba@kernel.org wrote:
> >On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:  
> >> Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:  
> >> 
> >> Nope, I reviewed internally, that's why the tag was taken.
> >>   
> >> Well, For the rest of the notifications, we have NEW/DEL commands.
> >> However in this case, as "eswitch" is somehow a subobject, there is no
> >> NEW/DEL value defined. I'm fine with using GET for notifications for it.
> >> I'm also okay with adding new ID, up to you.  
> >
> >Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
> >easier / possible to use the same socket for requests and notifications.  
> 
> Well, you still can use the same socket with just ESWITCH_GET. Request
> messages are going from userspace, notifications from kernel, there is
> no mixup.

AFAICT DEVLINK_CMD_ESWITCH_GET is already used from kernel.
We could technically use the seq to differentiate but that's not very
generic.

> For the sake of consistency, shouldn't the name be ESWITCH_NEW?

No preference on the naming, we can go with _NEW, tho, as I think Parav
is alluding to, we don't send _NEW when device is created (which would
be the natural fit for _NEW). Perhaps we should?

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jiri Pirko]

Fri, Nov 21, 2025 at 03:48:13PM +0100, kuba@kernel.org wrote:
>On Fri, 21 Nov 2025 09:35:24 +0100 Jiri Pirko wrote:
>> Thu, Nov 20, 2025 at 03:52:23PM +0100, kuba@kernel.org wrote:
>> >On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:  
>> >> Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@kernel.org wrote:  
>> >> 
>> >> Nope, I reviewed internally, that's why the tag was taken.
>> >>   
>> >> Well, For the rest of the notifications, we have NEW/DEL commands.
>> >> However in this case, as "eswitch" is somehow a subobject, there is no
>> >> NEW/DEL value defined. I'm fine with using GET for notifications for it.
>> >> I'm also okay with adding new ID, up to you.  
>> >
>> >Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
>> >easier / possible to use the same socket for requests and notifications.  
>> 
>> Well, you still can use the same socket with just ESWITCH_GET. Request
>> messages are going from userspace, notifications from kernel, there is
>> no mixup.
>
>AFAICT DEVLINK_CMD_ESWITCH_GET is already used from kernel.

You are right.


>We could technically use the seq to differentiate but that's not very
>generic.
>
>> For the sake of consistency, shouldn't the name be ESWITCH_NEW?
>
>No preference on the naming, we can go with _NEW, tho, as I think Parav
>is alluding to, we don't send _NEW when device is created (which would
>be the natural fit for _NEW). Perhaps we should?

devlink_notify(devlink, DEVLINK_CMD_NEW); - is this what you mean by
"when device is created"?

If you mean DEVLINK_CMD_ESWITCH_NEW, then I believe we should send it
both when
1) device is registered, right after we send devlink_notify(devlink, DEVLINK_CMD_NEW);
   in devlink_notify_register()
2) when eswitch config is changed in devlink_nl_eswitch_set_doit()

And for the sake of completeness, we should also send
DEVLINK_CMD_ESWITCH_DEL from devlink_notify_unregister().

Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

[Jakub Kicinski]

On Sat, 22 Nov 2025 10:14:35 +0100 Jiri Pirko wrote:
> >> For the sake of consistency, shouldn't the name be ESWITCH_NEW?  
> >
> >No preference on the naming, we can go with _NEW, tho, as I think Parav
> >is alluding to, we don't send _NEW when device is created (which would
> >be the natural fit for _NEW). Perhaps we should?  
> 
> devlink_notify(devlink, DEVLINK_CMD_NEW); - is this what you mean by
> "when device is created"?
> 
> If you mean DEVLINK_CMD_ESWITCH_NEW, then I believe we should send it
> both when
> 1) device is registered, right after we send devlink_notify(devlink, DEVLINK_CMD_NEW);
>    in devlink_notify_register()
> 2) when eswitch config is changed in devlink_nl_eswitch_set_doit()
> 
> And for the sake of completeness, we should also send
> DEVLINK_CMD_ESWITCH_DEL from devlink_notify_unregister().

Sounds right!