Message-ID: <YNiVWhoqyHSVa+K4@lunn.ch>
Date:   Sun, 27 Jun 2021 17:12:26 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        jiri@...dia.com, vladyslavt@...dia.com, moshe@...dia.com,
        vadimp@...dia.com, mkubecek@...e.cz, mlxsw@...dia.com,
        Ido Schimmel <idosch@...dia.com>
Subject: 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:
> > > 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,
> 
> > 
> > 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.
> 
> > 
> > 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

Powered by blists - more mailing lists