netdev - Re: [RFC PATCH net-next] net: ethtool: add support for forward error correction 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] [day] [month] [year] [list]

Message-ID: <CAKWE-XqT8kBckOB_CgPsjMo5WkYfPdvZPeWY1XZwiqiAnBVcZQ@mail.gmail.com>
Date:   Tue, 8 Nov 2016 13:33:47 -0800
From:   Vidya Sagar Ravipati <vidya@...ulusnetworks.com>
To:     Gal Pressman <galp.dev@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        "John W. Linville" <linville@...driver.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Gal Pressman <galp@...lanox.com>,
        netdev <netdev@...r.kernel.org>,
        Oded Wertheim <odedw@...lanox.com>,
        Ariel Almog <ariela@...lanox.com>,
        Yuval Mintz <Yuval.Mintz@...gic.com>,
        Tzahi Oved <tzahio@...lanox.com>,
        Roee Shapiro <roees@...lanox.com>,
        Aviad Raveh <aviadr@...lanox.com>,
        Dustin Byford <dustin@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [RFC PATCH net-next] net: ethtool: add support for forward error
 correction modes

On Thu, Nov 3, 2016 at 6:24 AM, Gal Pressman <galp.dev@...il.com> wrote:
>
>
> On 25/10/2016 05:50, Vidya Sagar Ravipati wrote:
>> SET FEC option:
>> root@tor: ethtool --set-fec  swp1 encoding [off | RS | BaseR | auto] autoneg [off | on]
>>
>> Encoding: Types of encoding
>> Off    :  Turning off any encoding
>> RS     :  enforcing RS-FEC encoding on supported speeds
>> BaseR  :  enforcing Base R encoding on supported speeds
>> Auto   :  Default FEC settings  for  divers , and would represent
>
> divers? :)
Drivers :)
>
>>           asking the hardware to essentially go into a best effort mode.
>>
>> Here are a few examples of what we would expect if encoding=auto:
>> - if autoneg is on, we are  expecting FEC to be negotiated as on or off
>>   as long as protocol supports it
>> - if the hardware is capable of detecting the FEC encoding on it's
>>       receiver it will reconfigure its encoder to match
>> - in absence of the above, the configuration would be set to IEEE
>>   defaults.
>
> Not sure I follow, why do we need an autoneg option if encoding type can be set to auto?
Auto is one of the FEC configuration modes  which indicates  the
drivers to set the IEEE defaults based on speed/duplex combination of
the port. i.e. RS FEC mode will be set in case of 100G/full

Auto negotiation is the configuration for the link  to negotiate the
FEC capabilities and different FEC modes with other endpoint  using
encoded bits D44:47 in base link code word.