Re: [RFC PATCH net-next 0/4] ethtool: Add ability to flash and query transceiver modules' firmware

From: Jakub Kicinski <kuba@kernel.org>
To: Ido Schimmel <idosch@idosch.org>
Cc: Michal Kubecek <mkubecek@suse.cz>,
	netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch,
	pali@kernel.org, jacob.e.keller@intel.com, vadimp@nvidia.com,
	mlxsw@nvidia.com, Ido Schimmel <idosch@nvidia.com>
Subject: Re: [RFC PATCH net-next 0/4] ethtool: Add ability to flash and query transceiver modules' firmware
Date: Tue, 30 Nov 2021 08:59:36 -0800	[thread overview]
Message-ID: <20211130085936.669eb48c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <YaXzCKEwuICECkyz@shredder>

On Tue, 30 Nov 2021 11:46:48 +0200 Ido Schimmel wrote:
> > As I already mentioned, we should distinguish between ethtool API and
> > ethtool utility. It is possible to implement the flashing in devlink API
> > and let both devlink and ethtool utilities use that API.
> > 
> > I'm not saying ethtool API is a wrong choice, IMHO either option has its
> > pros and cons.  
> 
> What are the cons of implementing it in ethtool? It seems that the only
> thing devlink has going for it is the fact that it supports devlink
> device firmware update API, but it cannot be used as-is and needs to be
> heavily extended (e.g., asynchronicity is a must, per-port as opposed to
> per-device). It doesn't support any transceiver module API, as opposed
> to ethtool.

The primary advantage is that we could hopefully share some of the
infrastructure around versioning, A/B image selection, activation and
error reporting. All those are universal firmware update problems.

> > I'm just trying to point out that implementation in devlink API does
> > not necessarily mean one cannot use the ethtool to use the feature.  
> 
> I agree it can be done, but the fact that something can be done doesn't
> mean it should be done. If I'm extending devlink with new uAPI, then I
> will add support for it in devlink(8) and not ethtool(8) and vice versa.

I'm not dead set on SFP flashing being in devlink, I just think it's
the right choice, but at the end of the day - your call.

From my experience working with and on FW management in production
(using devlink) I don't think that the "rest of the SFP API is in
ethtool" motivation matters in practice. At least not in my
environment. Upgrading firmware is a process that's more concerned with
different device components than the functionality those devices
actually provide. For a person writing FW update automation its better
if they have one type of API to talk to. IOW nobody cares if e.g. the FW
upgrade on a soundcard is via the sound API.

When automation gets more complex (again versioning, checking if there
is degradation and FW has to be re-applied, checking if upgrades can be
live, or device has to be reset, power cycled, etc) plugging into a
consistent API is what matters most.