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]

Message-ID: <CAJieiUj1e+PZ+3BS=CGACqNMZoX-F7SFR4OyCgv6VPJAaxq1Qg@mail.gmail.com>
Date:   Fri, 28 Jul 2017 23:29:56 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Jakub Kicinski <kubakici@...pl>,
        "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>,
        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, Jul 28, 2017 at 10:29 AM, Andrew Lunn <andrew@...n.ch> wrote:
> On Fri, Jul 28, 2017 at 09:46:20AM -0700, Jakub Kicinski wrote:
>> 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.
>
> You might also find this interesting:
>
> https://py3.patchwork.dja.id.au/patch/42846/
>
> Most of the rest of the series has been reviewed, so i don't think it
> will be too long before it is in the kernel.
>

yes, we are excited about this work as well..