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

On Tue, 30 Nov 2021 11:46:48 +0200 Ido Schimmel wrote:

quoted

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.

quoted

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.