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 15:43:06 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Casey Leedom <leedom@...lsio.com>, 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

On Thu, 6 Jul 2017 21:53:46 +0000, Casey Leedom wrote:
> | From: Jakub Kicinski <kubakici@...pl>
> | Sent: Thursday, July 6, 2017 12:02 PM
> |
> | IMHO if something gets replugged all the settings should be reset.
> | I feel that it's not entirely unlike replugging a USB adapter.  Perhaps
> | we should introduce some (devlink) notifications for SFP module events
> | so userspace can apply whatever static user config it has?
> 
> Absolutely a valid approach.  As are all of the ones I outlined.
> 
> 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.

> As I noted in my previous letter: this is something new that we've never
> faced before with any prior networking technology.  All previous networking
> technologies had a static set of Physical Port Capabilities fixed from the
> moment a Host Diver/Firmware first see a Port.  We're now facing a situation
> where these can change dynamically from moment to moment based on what
> Transceiver Module is inserted.
> 
> With regard to this "architectural" issue, one way of trying to tease out
> what model will be the simplest for users to work with is to ask: how do
> users conceive of a "Port"?  I.e. when a user requests that a particular
> Link Parameter be applied to a Port, are they thinking that it only applies
> to the current instantaneous combination of Adapter Transceiver Module Cage
> + Transceiver Module?  Or do they conceptualize a "Port" as being a higher
> level entity?

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...