Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes
From: Jakub Kicinski <hidden>
Date: 2017-07-06 22:43:10
On Thu, 6 Jul 2017 21:53:46 +0000, Casey Leedom wrote:
| From: Jakub Kicinski [off-list ref] | 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...