From: Andrew Lunn <andrew@lunn.ch>
To: Edward Cree <ecree@solarflare.com>
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 17:39:42 +0200 [thread overview]
Message-ID: <20180928153942.GM12979@lunn.ch> (raw)
In-Reply-To: <7451b1dc-1cac-6cb2-fe56-8c09eac8aefb@solarflare.com>
> For us, those semantics make sense (our HW has a notion of 'supported'
> and 'requested' bits for each FEC type for each of local-device, cable
> and link-partner, and uses the strongest FEC mode that's supported by
> everyone and requested by anyone); but if something else is a better fit
> for your hardware I wouldn't worry too much about the inconsistency —
> people using this functionality will hopefully have read the hardware's
> user manual...
I wonder how true that will be in 5 years time, about reading the
manual? SFP sockets are starting to appear in consumer devices. There
are some Marvell SoC reference boards with SFP and SFP+. Broadcom also
have some boards with SFP. With time, SFP will move out of the data
centre and comms rack and into more everyday systems. In such context,
reading the manual becomes less likely. It would be nice to avoid a
future inconsistent mess caused be this sentiment now.
Andrew
next prev parent reply other threads:[~2018-09-28 22:04 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 [this message]
2018-09-28 16:11 ` Edward Cree
2018-09-28 16:45 ` Andrew Lunn
2018-09-28 17:30 ` Edward Cree
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=20180928153942.GM12979@lunn.ch \
--to=andrew@lunn.ch \
--cc=ariela@mellanox.com \
--cc=arielalmogworkemails@gmail.com \
--cc=dirk.vandermerwe@netronome.com \
--cc=dustin@cumulusnetworks.com \
--cc=ecree@solarflare.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).