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-next>] [day] [month] [year] [list]

Message-ID: <20191113135925.GB27785@lunn.ch>
Date:   Wed, 13 Nov 2019 14:59:25 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Adrian Pop <popadrian1996@...il.com>
Cc:     netdev@...r.kernel.org, linville@...driver.com
Subject: Re: [PATCH] ethtool: Add QSFP-DD support

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