netdev - Re: [PATCH net-next 1/3] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170628062734.mhtvmnpviskat47k@cumulusnetworks.com>
Date:   Tue, 27 Jun 2017 23:27:34 -0700
From:   Dustin Byford <dustin@...ulusnetworks.com>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>, davem@...emloft.net,
        linville@...driver.com, netdev@...r.kernel.org,
        vidya.chowdary@...il.com, olson@...ulusnetworks.com,
        leedom@...lsio.com, manojmalviya@...lsio.com, santosh@...lsio.com,
        yuval.mintz@...gic.com, odedw@...lanox.com, ariela@...lanox.com,
        galp@...lanox.com, jeffrey.t.kirsher@...el.com
Subject: Re: [PATCH net-next 1/3] net: ethtool: add support for forward error
 correction modes

Hi Jakub,

On Tue Jun 27 03:22, Jakub Kicinski wrote:
> On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > 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   :  IEEE defaults for the speed/medium combination
> 
> Just to be sure - does auto mean autonegotiate as defined by IEEE or
> some presets?  IIUC there is a notion of different length cables
> defaulting to different strength of FEC in 25GE?

In this context, "auto" doesn't mean autoneg.  Typically, if it's a
copper (CR) link autoneg has taken care of the FEC settings.  If you're
using sfecparam, you're probably dealing with optics where there is no
real autoneg.

Here, the term "auto", in its simplest implementation, would mean the
driver picks a preset based on the speed, cable (typically an SFF
cable), and hardware capability.  "IEEE defaults" in the comment refers
to a couple of tables you'll find in IEEE specs (sorry I can't dig them
up at the moment) that suggest FEC modes based on speed, medium
(CR/SR/LR) and perhaps length in the CR case.  So, yes, perhaps length
is part of the calculation for the appropriate "auto" mode.  This is
essentially why this patch set is important.  Drivers up until now can
be thought of as implementing "auto".  Sometimes that matches the
expectation of a link partner, especially if both sides support the
"IEEE defaults", but it's somewhat common for there to be a mismatch.
That can be because one side isn't using the "IEEE default" FEC mode for
the speed/medium/length, but it can also be because the hardware doesn't
support the most common FEC mode for a speed/medium/length.  We need a
way to explicitly set the FEC mode.  But, the hope is that "auto" is a
reasonable default.

		--Dustin