Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

[Jakub Kicinski <jakub.kicinski@netronome.com>]

On Thu, 6 Jul 2017 21:53:46 +0000, Casey Leedom wrote:
> | From: Jakub Kicinski <kubakici@wp.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...