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 18:45:53 +0200 [thread overview]
Message-ID: <20180928164553.GB22858@lunn.ch> (raw)
In-Reply-To: <0c1a3a90-e6f5-7f8e-044c-bd43e0cb830a@solarflare.com>
> I see where you're coming from, but if people start needing to manually
> configure FEC on their consumer devices, possibly we have bigger
> problems.
Yes, i agree with that. For the consumer market, SFPs needs to grow up
and start doing full and reliable auto-neg, just like copper Ethernet.
However, there is often an intermediate step after the really niche
market like TOR routers. Industrial applications start using this
stuff. There are a lot of planes flying today using SFPs for the
inflight entertainment systems. Fibre weights less than copper. It is
a somewhat specialist market, so you probably can still force them to
read the hardware manual, but i think they would prefer not to. And
i'm sure they are not the only industrial users. There are likely to
be more industrial users than TOR users.
In general, it is hard to know which APIs are going to remain Unix
Wizard level, and which are going to be used by mere mortals. So
ideally, we want consistency everywhere.
> I think the alternative, of finding a set of semantics that fits
> everyone's hardware and covers everyone's requirements, is likely to
> be difficult (and probably require changing the ethtool API).
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...
Andrew
next prev parent reply other threads:[~2018-09-28 23:10 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 [this message]
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=20180928164553.GB22858@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).