netdev - Re: [PATCH net-next v2 0/3] ethtool: support for forward error correction mode setting on a link

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:   Fri, 28 Jul 2017 09:46:20 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "John W. Linville" <linville@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Vidya Sagar Ravipati <vidya.chowdary@...il.com>,
        Dustin Byford <dustin@...ulusnetworks.com>,
        Dave Olson <olson@...ulusnetworks.com>,
        Casey Leedom <leedom@...lsio.com>,
        Gal Pressman <galp@...lanox.com>, Andrew Lunn <andrew@...n.ch>,
        Manoj Malviya <manojmalviya@...lsio.com>,
        Santosh Rastapur <santosh@...lsio.com>, yuval.mintz@...gic.com,
        odedw@...lanox.com, Ariel Almog <ariela@...lanox.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH net-next v2 0/3] ethtool: support for forward error
 correction mode setting on a link

On Fri, 28 Jul 2017 07:53:01 -0700, Roopa Prabhu wrote:
> On Thu, Jul 27, 2017 at 7:33 PM, Jakub Kicinski <kubakici@...pl> wrote:
> > On Thu, 27 Jul 2017 16:47:25 -0700, Roopa Prabhu wrote:  
> >> From: Roopa Prabhu <roopa@...ulusnetworks.com>
> >>
> >> Forward Error Correction (FEC) modes i.e Base-R
> >> and Reed-Solomon modes are introduced in 25G/40G/100G standards
> >> for providing good BER at high speeds. Various networking devices
> >> which support 25G/40G/100G provides ability to manage supported FEC
> >> modes and the lack of FEC encoding control and reporting today is a
> >> source for interoperability issues for many vendors.
> >> FEC capability as well as specific FEC mode i.e. Base-R
> >> or RS modes can be requested or advertised through bits D44:47 of base link
> >> codeword.
> >>
> >> This patch set intends to provide option under ethtool to manage and
> >> report FEC encoding settings for networking devices as per IEEE 802.3
> >> bj, bm and by specs.
> >>
> >> v2 :
> >>         - minor patch format fixes and typos pointed out by Andrew
> >>         - there was a pending discussion on the use of 'auto' vs
> >>           'automatic' for fec settings. I have left it as 'auto'
> >>           because in most cases today auto is used in place of
> >>           automatic to represent automatically generated values.
> >>           We use it in other networking config too. I would prefer
> >>           leaving it as auto.  
> >
> > On the subject of resetting the values when module is replugged I
> > assume what was previously described remains:
> >  - we always allow users to set the FEC regardless of the module type;
> >  - if user set an incorrect FEC for the module type (or module gets
> >    swapped) the link will be administratively taken down by either
> >    the driver or FW.
> >
> > Is that correct?  Am I misremembering?  
> 
> yes, correct. And possible future sfp hotplug events can give user-space
> more info to react to module type changes etc.

OK, if nobody else objects and we go with that - lets make sure we
document clearly those are expected :)  My concern is that if there is
ever 10G + RS FEC standard we don't want to end up in a situation where
some drivers silently ignore FEC settings in 10G and other apply it.
So let's make it clear what the intended Linux behaviour is.  It could
be in the ethtool man page, or the kernel somewhere.