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: <MWHPR12MB16008B0A63E099591C26C7E8C8D50@MWHPR12MB1600.namprd12.prod.outlook.com>
Date:   Thu, 6 Jul 2017 21:53:46 +0000
From:   Casey Leedom <leedom@...lsio.com>
To:     Jakub Kicinski <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 <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.

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?

Or, let's make it Very Concrete with a specific example:

 1. User applies some set of Link Parameters.

 2. User attempts to bring Link up but it doesn't come up.

 3. User decides to try a different cable on the grounds that the first
    cable may be bad.

 4. New cable is accidentally of a completely different type with completely
    different subsequent Physical Port Capabilities, not capable of supporting
    the user's selected Link Parameters.

 5. User realizes this accidental mis-selection, and swaps in a third cable,
    similar to the first cable.

 6. User attempts to bring the Link up with the third cable.

If we reset all of the user-specified Link Parameters at point #3 and/or #5,
then the user's requested Link Parameter settings from point #1 will no
longer be in effect at point #6.  Is this expected/desirable?

In our discussions (Dustin, I, and others), we felt that the answer to this
above scenario question was "no".  I.e. that users would have a persistent
memory of having applied a set of Link Parameter settings to the "Port" and
would be annoyed/confused if those settings were "arbitrarily" reset at some
indefinite time.

But, this is a discussion and a decision that needs to be made.  Regardless
of what people finally decide is the "Right Answer", it needs to be
extremely well documented, it needs to be executed uniformly, and we may
want to explicitly notify the user at the points where something
unexpected/confusing is occurring.  Say, in the "Reset Unsupportable Link
Parameters When Transceiver Module Is Changed" model that you advocate, when
the user's Link Parameter settings are reset.

Casey