[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8f639547-7e75-c749-55ed-bab8923df354@solarflare.com>
Date: Fri, 28 Sep 2018 18:30:40 +0100
From: Edward Cree <ecree@...arflare.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Ariel Almog <arielalmogworkemails@...il.com>,
<linville@...driver.com>,
Linux Netdev List <netdev@...r.kernel.org>,
<ganeshgr@...lsio.com>, <jakub.kicinski@...ronome.com>,
<dustin@...ulusnetworks.com>, <dirk.vandermerwe@...ronome.com>,
<shayag@...lanox.com>, <ariela@...lanox.com>
Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes
On 28/09/18 17:45, Andrew Lunn wrote:
> Now is a good time to change the API, since we are moving to a netlink
> socket. Which is why these questions were asked in the first place...
OK, well, I've posted sfc's semantics and view-from-the-hardware*; now
patiently waiting for other NIC vendors to chime in so we can try to
converge on something consistent.
Then again, since they've been CCed since the original patch three weeks
ago, we might be waiting a while :-(
Regarding Ariel Almog's suggested semantics, it seems like they have the
'auto' bit just encoding 'more than one non-auto bit', which is
redundant (i.e. off|rs is always off|rs|auto, whereas rs is never
rs|auto). I don't see how that would be useful.
-Ed
* One complication I left out: we actually have _three_ pairs of sup/req
bits, because we separate 'BaseR for 10G/40G/100G' from 'BaseR for
25G/50G'. I don't know the details of why our HW does this (or why
100G isn't lumped in with the other 25ers) but I think it has to do
with Horrific Ethernet Spec Arcana Man Was Not Meant To Know™.
Powered by blists - more mailing lists