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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 15 Nov 2019 19:00:49 +0000
From:   Adrian Pop <popadrian1996@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linville@...driver.com
Subject: Re: [PATCH] ethtool: Add QSFP-DD support

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@...n.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