netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Danielle Ratson <danieller@nvidia.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"sdf@google.com" <sdf@google.com>,
	"kory.maincent@bootlin.com" <kory.maincent@bootlin.com>,
	"maxime.chevallier@bootlin.com" <maxime.chevallier@bootlin.com>,
	"vladimir.oltean@nxp.com" <vladimir.oltean@nxp.com>,
	"przemyslaw.kitszel@intel.com" <przemyslaw.kitszel@intel.com>,
	"ahmed.zaki@intel.com" <ahmed.zaki@intel.com>,
	"richardcochran@gmail.com" <richardcochran@gmail.com>,
	"shayagr@amazon.com" <shayagr@amazon.com>,
	"paul.greenwalt@intel.com" <paul.greenwalt@intel.com>,
	"jiri@resnulli.us" <jiri@resnulli.us>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	mlxsw <mlxsw@nvidia.com>, Petr Machata <petrm@nvidia.com>,
	Ido Schimmel <idosch@nvidia.com>
Subject: Re: [PATCH net-next v5 04/10] ethtool: Add flashing transceiver modules' firmware notifications ability
Date: Tue, 30 Apr 2024 13:03:02 -0700	[thread overview]
Message-ID: <20240430130302.235d612d@kernel.org> (raw)
In-Reply-To: <DM6PR12MB45168DC7D9D9D7A5AE3E2B2DD81A2@DM6PR12MB4516.namprd12.prod.outlook.com>

On Tue, 30 Apr 2024 18:11:18 +0000 Danielle Ratson wrote:
> > Do we want to blast it to all listeners or treat it as an async reply?
> > We can save the seq and portid of the original requester and use reply, I
> > think.  
> 
> I am sorry, I am not sure I understood what you meant here... it
> should be an async reply, but not sure I understood your suggestion.
> 
> Can you explain please?

Make sure you have read the netlink intro, it should help fill in some
gaps I won't explicitly cover:
https://docs.kernel.org/next/userspace-api/netlink/intro.html

"True" notifications will have pid = 0 and seq = 0, while replies to
commands have those fields populated based on the request.

pid identifies the socket where the message should be delivered.
ethnl_multicast() assumes that it's zero (since it's designed to work
for notifications) and sends the message to all sockets subscribed to 
a multicast / notification group (ETHNL_MCGRP_MONITOR).

So that's the background. What you're doing isn't incorrect but I think
it'd be better if we didn't use the multicast group here, and sent the
messages as a reply - just to the socket which requested the flashing.
Still asynchronously, we just need to save the right pid and seq to use.

Two reasons for this:
 1) convenience, the user space socket won't have to subscribe to 
    the multicast group
 2) the multicast group is really intended for notifying about
    _configuration changes_ done to the system. If there is a daemon
    listening on that group, there's a very high chance it won't care
    about progress of the flashing. Maybe we can send a single
    notification that flashing has been completed but not "progress
    updates"

I think it should work.

> > > +void ethnl_module_fw_flash_ntf_err(struct net_device *dev,
> > > +				   char *err_msg, char *sub_err_msg) {
> > > +	char status_msg[120];
> > > +
> > > +	if (sub_err_msg)
> > > +		sprintf(status_msg, "%s, %s.", err_msg, sub_err_msg);
> > > +	else
> > > +		sprintf(status_msg, "%s.", err_msg);  
> > 
> > Hm, printing in the dot, and assuming sizeof err_msg + sub_err < 116 is a bit
> > surprising. But I guess you have a reason...
> > 
> > Maybe pass them separately to ethnl_module_fw_flash_ntf() then you can
> > nla_reserve() the right amount of space and sprintf() directly into the skb?  
> 
> I can get rid of the dot actually, would it be ok like that?

It'd still be better to splice the two strings and the comma directly
to the skb, rather than on the stack using a function which doesn't
check the bounds of the buffer :S

  reply	other threads:[~2024-04-30 20:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 13:30 [PATCH net-next v5 00/10] Add ability to flash modules' firmware Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 01/10] ethtool: Add ethtool operation to write to a transceiver module EEPROM Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 02/10] mlxsw: Implement " Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 03/10] ethtool: Add an interface for flashing transceiver modules' firmware Danielle Ratson
2024-04-30  2:14   ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 04/10] ethtool: Add flashing transceiver modules' firmware notifications ability Danielle Ratson
2024-04-30  3:11   ` Jakub Kicinski
2024-04-30 18:11     ` Danielle Ratson
2024-04-30 20:03       ` Jakub Kicinski [this message]
2024-05-01  7:53         ` Ido Schimmel
2024-05-01 14:37           ` Jakub Kicinski
2024-05-22 13:08             ` Danielle Ratson
2024-05-22 13:45               ` Jakub Kicinski
2024-05-22 13:56                 ` Danielle Ratson
2024-05-22 14:22                   ` Jakub Kicinski
2024-05-27 16:10                     ` Ido Schimmel
2024-05-27 16:30                       ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 05/10] include: netdevice: Add module firmware flashing in progress flag to net_device Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 06/10] net: sfp: Add more extended compliance codes Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 07/10] ethtool: cmis_cdb: Add a layer for supporting CDB commands Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 08/10] ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB Danielle Ratson
2024-04-24 13:30 ` [PATCH net-next v5 09/10] ethtool: Add ability to flash transceiver modules' firmware Danielle Ratson
2024-04-30  3:22   ` Jakub Kicinski
2024-04-24 13:30 ` [PATCH net-next v5 10/10] ethtool: Veto some operations during firmware flashing process Danielle Ratson
2024-04-30  3:23   ` Jakub Kicinski
2024-04-30 17:48     ` Danielle Ratson
2024-04-30 18:01       ` Jakub Kicinski

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=20240430130302.235d612d@kernel.org \
    --to=kuba@kernel.org \
    --cc=ahmed.zaki@intel.com \
    --cc=corbet@lwn.net \
    --cc=danieller@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=kory.maincent@bootlin.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=paul.greenwalt@intel.com \
    --cc=petrm@nvidia.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=richardcochran@gmail.com \
    --cc=sdf@google.com \
    --cc=shayagr@amazon.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).