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:   Thu, 6 Jul 2017 22:57:02 +0000
From:   Casey Leedom <leedom@...lsio.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "kubakici@...pl" <kubakici@...pl>
CC:     Dustin Byford <dustin@...ulusnetworks.com>,
        Andrew Lunn <andrew@...n.ch>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linville@...driver.com" <linville@...driver.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "vidya.chowdary@...il.com" <vidya.chowdary@...il.com>,
        "olson@...ulusnetworks.com" <olson@...ulusnetworks.com>,
        Manoj Malviya <manojmalviya@...lsio.com>,
        Santosh Rastapur <santosh@...lsio.com>,
        "yuval.mintz@...gic.com" <yuval.mintz@...gic.com>,
        "odedw@...lanox.com" <odedw@...lanox.com>,
        "ariela@...lanox.com" <ariela@...lanox.com>,
        "galp@...lanox.com" <galp@...lanox.com>,
        "jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH net-next 1/3] net: ethtool: add support for forward error
 correction modes

| From: Jakub Kicinski <jakub.kicinski@...ronome.com>
| Sent: Thursday, July 6, 2017 3:43 PM
|     
| On Thu, 6 Jul 2017 21:53:46 +0000, Casey Leedom wrote:
| > 
| > But, and far more importantly, ideally _*ANY*_ such decision is made at an
| > architectural level to apply to all Link Parameters and Vendor Products.
| > The last thing a user wants to deal with is a hodge-podge of different
| > policies for different adapters from different vendors.
| 
| Agreed.  Once we decided we should make the expected behaviour very
| clear the everyone.
| 
| Sorry if I'm misunderstanding - are you suggesting we should keep the
| speed settings if hand-selected?  My feeling is those should be reset
| if they are incompatible with the module.

Again, just to be perfectly clear, I don't think that there's a perfect
solution to this.  My personal feeling is that we need to think through all
of the usage scenarios and see what happens in the various models,
and more importantly, how easily we can explain the inevitable
repercussions to users.  Again, the "simplest model wins" philosophy.

But to your specific question: yes, I am saying that if the user selected
25Gb/s and accidentally swapped in a 10Gb/s cable, and then
swapped a different {100,25}Gb/s cable back in, the advertised
Speed(s) should be 25Gb/s with the newest cable, respecting
the original Link Parameter setting with the first cable.

And again, I don't believe that we'll come up with a perfect solution.
But hopefully we can come up with an abstraction model that's
easy to understand and use.  (And requires the fewest changes
to current accepted practices.)

| Hm.  I'm beginning to come around on this.  If my understanding of PHY
| sub-layers is correct the FEC layer shouldn't be reset on module
| unplug.  OTOH when someone replaces a DAC with an optical module,
| keeping FEC around is not going to do any good to users...

When I first stumbled across this issue several months ago I though
I must be dense.  Nothing this simple should be this complicated.
It's been extremely gratifying to find others similarly flummoxed ... :-)

Casey