Re: [RFC PATCH net-next 0/4] ethtool: Add ability to write to transceiver module EEPROMs

On Sun, Jun 27, 2021 at 01:33:13PM +0300, Ido Schimmel wrote:

On Thu, Jun 24, 2021 at 10:27:13PM +0200, Andrew Lunn wrote:

quoted

quoted

I fail to understand this logic. I would understand pushing
functionality into the kernel in order to create an abstraction for user
space over different hardware interfaces from different vendors. This is
not the case here. Nothing is vendor specific. Not to the host vendor
nor to the module vendor.

Hi Ido

Hi Andrew,

quoted

My worry is, we are opening up an ideal vector for user space drivers
for SFPs. And worse still, closed source user space drivers. We have
had great success with switchdev, over a hundred supported switches,
partially because we have always pushed back against kAPIs which allow
user space driver, closed binary blobs etc.

I don't think it's a correct comparison. Switch ASICs don't have a
standardized interface towards the host. It is therefore essential that
the kernel will abstract these differences to user space.

quoted

We have the choice here. We can add a write method to the kAPI, add
open source code to Ethtool using that API, and just accept people are
going to abuse the API for all sorts of horrible things in user space.
Or we can add more restrictive kAPIs, put more code in the kernel, and
probably limit user space doing horrible things. Maybe as a side
effect, SFP vendors contribute some open source code, rather than
binary blobs?

I didn't see any code or binary blobs from SFP vendors and I'm not sure
how they can provide these either. Their goal is - I believe - to sell
as much modules as possible to what the standard calls "systems
manufactures" / "system integrators". Therefore, they cannot make any
assumptions about the I2C connectivity (whether to the ASIC or the CPU),
the operating system running on the host and the user interface (ioctl /
netlink etc).

Given all these moving parts, I don't see how they can provide any
tooling. It is in their best interest to simply follow the standard and
make the tooling a problem of the "systems manufactures" / "system
integrators". In fact, the user who requested this functionality claims:
"the cable vendors don't develop the tools to burn the FW since the
vendors claim that the CMIS is supported". The user also confirmed that
another provider "is able to burn the FW for the cables from different
vendors".

Hi Ido

This API is not just about CMIS, it covers any I2C connected SFP
device. I'm more involved in the lower end, 1G, 2.5G and 10G. Devices
in this category seem to be very bad a following the standards. GPON
is especially bad, and GPON manufactures don't seem to care their
devices don't follow the standard, they assume the Customer Premises
Equipment is going to run software to work around whatever issues
their specific GPON has, maybe they provide driver code? The API you
are adding would be ideal for putting that driver in user space, as a
binary blob. That is going to make it harder for us to open up the
many millions of CPE used in FTTH. And there are people attempting to
do that.

If devices following CMIS really are closely following the standard
that is great. We should provide tooling to do firmware upgrade. But
at the same time, we don't want to aid those who go against the
standards and do their own thing. And it sounds like in the CMIS
world, we might have the power to encourage vendors to follow CMIS,
"Look, firmware upgrade just works for the competitors devices, why
should i use your device when it does not work?"

I just want to make sure we are considering the full range of devices
this new API will cover. From little ARM systems with 1G copper and
FTTH fibre ports through to big TOR systems with large number of 100G
ports.  If CMIS is well support by vendors, putting the code into the
kernel, as a loadable module, might be the better solution for the
whole range of devices the kernel needs to support.

      Andrew