From: Edward Cree <ecree@solarflare.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Ariel Almog <arielalmogworkemails@gmail.com>,
<linville@tuxdriver.com>,
Linux Netdev List <netdev@vger.kernel.org>,
<ganeshgr@chelsio.com>, <jakub.kicinski@netronome.com>,
<dustin@cumulusnetworks.com>, <dirk.vandermerwe@netronome.com>,
<shayag@mellanox.com>, <ariela@mellanox.com>
Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes
Date: Fri, 28 Sep 2018 18:30:40 +0100 [thread overview]
Message-ID: <8f639547-7e75-c749-55ed-bab8923df354@solarflare.com> (raw)
In-Reply-To: <20180928164553.GB22858@lunn.ch>
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™.
prev parent reply other threads:[~2018-09-28 23:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 17:54 [PATCH ethtool] ethtool: support combinations of FEC modes Edward Cree
2018-09-17 19:52 ` John W. Linville
2018-09-19 14:41 ` Michal Kubecek
2018-09-19 15:33 ` Andrew Lunn
2018-09-19 15:49 ` Michal Kubecek
2018-09-19 15:38 ` Edward Cree
2018-09-19 15:56 ` Michal Kubecek
2018-09-19 16:06 ` [RFC PATCH ethtool] ethtool: better syntax for " Edward Cree
2018-09-20 13:46 ` Michal Kubecek
2018-10-01 18:59 ` John W. Linville
2018-10-04 14:08 ` John W. Linville
2018-10-04 14:43 ` Michal Kubecek
2018-10-04 16:06 ` Edward Cree
2018-10-04 19:41 ` John W. Linville
[not found] ` <811cf92b-51ed-4a8f-4b69-113cdd8473df@mellanox.com>
2018-09-26 8:47 ` [PATCH ethtool] ethtool: support " Ariel Almog
2018-09-28 12:58 ` Edward Cree
2018-09-28 15:39 ` Andrew Lunn
2018-09-28 16:11 ` Edward Cree
2018-09-28 16:45 ` Andrew Lunn
2018-09-28 17:30 ` Edward Cree [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f639547-7e75-c749-55ed-bab8923df354@solarflare.com \
--to=ecree@solarflare.com \
--cc=andrew@lunn.ch \
--cc=ariela@mellanox.com \
--cc=arielalmogworkemails@gmail.com \
--cc=dirk.vandermerwe@netronome.com \
--cc=dustin@cumulusnetworks.com \
--cc=ganeshgr@chelsio.com \
--cc=jakub.kicinski@netronome.com \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=shayag@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.