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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 27 Jun 2017 23:41:10 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Dustin Byford <dustin@...ulusnetworks.com>
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

On Tue, 27 Jun 2017 23:27:34 -0700, Dustin Byford wrote:
> 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.


Thanks for the explanation!