[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180928153942.GM12979@lunn.ch>
Date: Fri, 28 Sep 2018 17:39:42 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Edward Cree <ecree@...arflare.com>
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
> 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
Powered by blists - more mailing lists