netdev - Re: [PATCH ethtool] ethtool: support combinations of FEC modes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7451b1dc-1cac-6cb2-fe56-8c09eac8aefb@solarflare.com>
Date:   Fri, 28 Sep 2018 13:58:40 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Ariel Almog <arielalmogworkemails@...il.com>
CC:     <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

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