From mboxrd@z Thu Jan  1 00:00:00 1970
From: Edward Cree <ecree@solarflare.com>
Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes
Date: Fri, 28 Sep 2018 17:11:41 +0100
Message-ID: <0c1a3a90-e6f5-7f8e-044c-bd43e0cb830a@solarflare.com>
References: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com>
 <811cf92b-51ed-4a8f-4b69-113cdd8473df@mellanox.com>
 <CABvr3-Hvq4nsNEfJH+ic_pFGup2iAUGjcDfXni33a6LZoSZOYw@mail.gmail.com>
 <7451b1dc-1cac-6cb2-fe56-8c09eac8aefb@solarflare.com>
 <20180928153942.GM12979@lunn.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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>
To: Andrew Lunn <andrew@lunn.ch>
Return-path: <netdev-owner@vger.kernel.org>
Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:54786 "EHLO
        dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1726934AbeI1WgV (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 28 Sep 2018 18:36:21 -0400
In-Reply-To: <20180928153942.GM12979@lunn.ch>
Content-Language: en-GB
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 28/09/18 16:39, Andrew Lunn wrote:
> 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
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.
Ethtool FEC control is for those situations where autoneg, autodetect,
 autoconfigure etc. don't work (e.g. owing to out-of-spec switches, or
 just a user wanting to disable FEC to save a few hundred nanos).  I
 would hope that FEC won't show up in consumer gear until these kinds
 of problems have settled down somewhat.

Perhaps we can add something to the man page saying that not only can
 the semantics vary from NIC to NIC, but that the semantics for a given
 NIC might change in the future?  Then if in five years' time we know
 what the Right Thing™ is, we can move everyone over to that (with
 appropriately *loud* release-notes).

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).

-Ed