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 13:58:40 +0100
Message-ID: <7451b1dc-1cac-6cb2-fe56-8c09eac8aefb@solarflare.com>
References: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com>
 <811cf92b-51ed-4a8f-4b69-113cdd8473df@mellanox.com>
 <CABvr3-Hvq4nsNEfJH+ic_pFGup2iAUGjcDfXni33a6LZoSZOYw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Cc: <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: Ariel Almog <arielalmogworkemails@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:36442 "EHLO
        dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1726068AbeI1TW2 (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 28 Sep 2018 15:22:28 -0400
In-Reply-To: <CABvr3-Hvq4nsNEfJH+ic_pFGup2iAUGjcDfXni33a6LZoSZOYw@mail.gmail.com>
Content-Language: en-GB
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 26/09/18 09:47, Ariel Almog wrote:
> I was won
Truncated sentence?  ("... wondering"?)

> I find the ability to set off, auto and specific FEC mode in the same
> command confusing.
I didn't try to define semantics here since each driver currently does
 something slightly different.  Probably the configuration space that's
 meaningful is different for each piece of hardware anyway.

> Here are some examples
>
> 1. What is the expected result of 'off' & other FEC mode such as 'RS'?
>   -'off'?
>   -'RS'?
>   -automatic selection {'off','RS'}? w/o setting of auto?
In sfc, 'off' overrides everything else.

The meaning (again, in sfc) of a combination of 'auto' and a specific mode
 (e.g. 'rs') is "prefer the specified mode, but fall back to autoneg if
 it's not supported".  The combination {'rs', 'baser'} (with or without
 'auto') means "use the strongest FEC supported", i.e. it will attempt to
 negotiate FEC even if the cable & link partner don't request it (e.g. a
 short cable).

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

-Ed