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]

Message-ID: <20170628180008.42059797@cakuba.netronome.com>
Date:   Wed, 28 Jun 2017 18:00:08 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Dustin Byford <dustin@...ulusnetworks.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        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 Wed, 28 Jun 2017 14:47:51 -0700, Dustin Byford wrote:
> Hi Andrew,
> 
> On Wed Jun 28 15:41, Andrew Lunn wrote:
> > On Tue, Jun 27, 2017 at 03:22:39AM -0700, 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?  
> > 
> > I don't know this field very well. Is this confusion likely to happen
> > a lot? Is there a better name for Auto which is less likely to be
> > confused?  
> 
> You're not the first, or the second to ask that question.  I agree it
> could use clarification.
> 
> I always read auto in this context as automatic rather than autoneg.
> The best I can come up with is to perhaps fully spell out "automatic" in
> the documentation and the associated uapi enums.  It's accurate, and
> hopefully different enough from "autoneg" to hint people away from the
> IEEE autoneg concept.

So perhaps just "default"?  Even saying something like ieee-selected
doesn't really help, because apparently there are two autonegs defined
- IEEE one and a "consortium" one...