Re: [PATCH] ethtool: Add QSFP-DD support

[Adrian Pop <popadrian1996@gmail.com>]

Hi Andrew

You are right about defining a KAPI. Unfortunately due to the nature
of my company's business we can't really mainline our driver. I'll try
to add the QSFP-DD support myself in the future, although I have
nothing planned at the moment. Until then, maybe this thread will be
helpful for any other contributors that will decide to work on a
driver. As I said, to provide the same stats for QSFP-DD as for QSFP,
ethtool needs an extra page. My pull request is well documented and
contains information about this.

Adrian

On Wed, 13 Nov 2019 at 13:59, Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Nov 13, 2019 at 12:56:51PM +0000, Adrian Pop wrote:
> > Hi Andrew!
> >
> > Thank you for your email. At the moment, there are no in-kernel drivers that
> > require this support (the 1st version of the Common Management Interface
> > Specification for the QSFP-DD 8X pluggable transceivers came out this year in
> > May [0]). I first came across implementing this extra functionality to ethtool
> > at my company, where we use a custom driver for a NIC that works with the new
> > QSFP-DD transceivers. All the ethtool readings for QSFP-DD were correct and I
> > can provide a sample if needed. Another example of somebody putting QSFP-DD
> > support in their products is Exablaze with their ExaNIC [1] and I'm sure that
> > with time there will be more. Unfortunately at the moment I'm not able to
> > provide help with an update on the mainline driver in the kernel.
> >
> > I know that ETH_MODULE_SFF_8436_MAX_LEN is 640 bytes, but to provide for
> > QSFP-DD all the stats as for QSFP (basically to maintain the same behavior/
> > functionality), we came to the conclusion that we need to read more pages than
> > before, since the memory map is different and the data is more spread around.
> >
> > Please let me know if you have any other feedback and/or suggestions for the
> > patch.
>
> Hi Adrian
>
> You are defining a kernel API here. It is very unusual to define a
> KAPI without the mainline kernel actually implementing it. So in my
> opinion, we need an in kernel implementation first.
>
> I guess you are not going to mainline your driver? The ExaNIC is also
> a long way from being mainline'able.
>
> Could i suggest you extend drivers/net/phy/sfp.c to support QSFP-DD?
> Or maybe one of Intels or Mellanox drivers? Basically, any hardware
> with an in kernel driver you can get your hands on and test. Maybe you
> already have something which you use of interoperability testing.
>
>      Andrew