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

On Mon, Nov 29, 2021 at 09:37:24AM -0800, Jakub Kicinski wrote:

On Sat, 27 Nov 2021 19:45:26 +0200 Ido Schimmel wrote:

quoted

This patchset extends the ethtool netlink API to allow user space to
both flash transceiver modules' firmware and query the firmware
information (e.g., version, state).

The main use case is CMIS compliant modules such as QSFP-DD. The CMIS
standard specifies the interfaces used for both operations. See section
7.3.1 in revision 5.0 of the standard [1].

Despite the immediate use case being CMIS compliant modules, the user
interface is kept generic enough to accommodate future use cases, if
these arise.

The purpose of this RFC is to solicit feedback on both the proposed user
interface and the device driver API which are described in detail in
patches #1 and #3. The netdevsim patches are for RFC purposes only. The
plan is to implement the CMIS functionality in common code (under lib/)
so that it can be shared by MAC drivers that will pass function pointers
to it in order to read and write from their modules EEPROM.

ethtool(8) patches can be found here [2].

Immediate question I have is why not devlink. We purposefully moved 
FW flashing to devlink because I may take long, so doing it under
rtnl_lock is really bad. Other advantages exist (like flashing
non-Ethernet ports). Ethtool netlink already existed at the time.

Device firmware flashing doesn't belong in devlink because of locking
semantics. It belongs in devlink because you are updating the firmware
of the device, which can instantiate multiple netdevs. For multi-port
devices, it always seemed weird to tell users "choose some random port
and use it for 'ethtool -f'". I remember being asked if the command
needs to be run for all swp* netdevs (no).

On the other hand, each netdev corresponds to a single transceiver
module and each transceiver module corresponds to a single netdev
(modulo split which is a user configuration).

In addition, users are already dumping the EEPROM contents of
transceiver modules via ethtool and also toggling their settings.

Given the above, it's beyond me why we should tell users to use anything
other than ethtool to update transceiver modules' firmware.

Also, note that an important difference from the devlink implementation
is that this mechanism is asynchronous, which allows the firmware on
multiple modules to be updated simultaneously.