[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<CY8PR12MB71955C13A7D4659B7A55EBDCDCD7A@CY8PR12MB7195.namprd12.prod.outlook.com>
Date: Wed, 19 Nov 2025 13:49:13 +0000
From: Parav Pandit <parav@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "davem@...emloft.net"
<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
"pabeni@...hat.com" <pabeni@...hat.com>, "horms@...nel.org"
<horms@...nel.org>, Jiri Pirko <jiri@...dia.com>
Subject: RE: [PATCH net-next] devlink: Notify eswitch mode changes to devlink
monitor
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: 19 November 2025 01:46 AM
>
> On Tue, 18 Nov 2025 05:25:23 +0000 Parav Pandit wrote:
> > > From: Jakub Kicinski <kuba@...nel.org>
> > > Sent: 18 November 2025 09:11 AM
> > >
> > > On Sat, 15 Nov 2025 04:51:25 +0200 Parav Pandit wrote:
> > > > + err = devlink_nl_eswitch_fill(msg, devlink,
> > > DEVLINK_CMD_ESWITCH_SET,
> > >
> > > I've never seen action command ID being used for a notification.
> > > Either use an existing type which has the same message format, or if
> > > no message which naturally fits exists allocate a new ID.
> >
> > I am not sure fully.
> > 1. devlink_notify() uses DEVLINK_CMD_NEW.
> >
> > 2. devlink_port_notify() uses DEVLINK_CMD_PORT_NEW which is the input
> > cmd on port creation supplied by the user space.
> >
> > 3. devlink_params_notify_register() uses DEVLINK_CMD_PARAM_NEW.
> >
> > Do you mean #1 and #3 are not user-initiated commands, hence such an
> > action command ID is ok vs #2 is not ok? I probably misunderstanding
> > your comment.
>
> Let me put it more simply at some cost to accuracy..
> The notification types and command ids usually match the response to a GET
> command. Please TAL at the messages which are generated in response to a
> GET for the objects you listed...
>
Got it.
Will change to reuse the id same as GET method.
In the eswitch case it is DEVLINK_CMD_ESWITCH_GET.
It fits the existing get command.
Ideally a change opcode like DPLL_CMD_DEVICE_CHANGE_X would be good too.
But ESWITCH_GET seems good enough as we don't have ESWITCH_NEW/ESWITCH_DEL.
> Netlink command IDs are not required to match in a request-response pair. In
> "modern" families we recommend that they do match, not because the old
> model was wrong, but because a casual contributors usually got it wrong.
Sending v1.
Thank you for the good explanation.
Powered by blists - more mailing lists