From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes Date: Fri, 28 Sep 2018 17:39:42 +0200 Message-ID: <20180928153942.GM12979@lunn.ch> References: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com> <811cf92b-51ed-4a8f-4b69-113cdd8473df@mellanox.com> <7451b1dc-1cac-6cb2-fe56-8c09eac8aefb@solarflare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Ariel Almog , linville@tuxdriver.com, Linux Netdev List , ganeshgr@chelsio.com, jakub.kicinski@netronome.com, dustin@cumulusnetworks.com, dirk.vandermerwe@netronome.com, shayag@mellanox.com, ariela@mellanox.com To: Edward Cree Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:48748 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729362AbeI1WEN (ORCPT ); Fri, 28 Sep 2018 18:04:13 -0400 Content-Disposition: inline In-Reply-To: <7451b1dc-1cac-6cb2-fe56-8c09eac8aefb@solarflare.com> Sender: netdev-owner@vger.kernel.org List-ID: > 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