> -----Original Message----- > From: [email protected] [mailto:netdev- > [email protected]] On Behalf Of Jakub Kicinski > Sent: Thursday, July 06, 2017 12:02 PM > To: Casey Leedom <[email protected]> > Cc: Dustin Byford <[email protected]>; Andrew Lunn > <[email protected]>; Roopa Prabhu <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Manoj Malviya > <[email protected]>; Santosh Rastapur <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; Kirsher, Jeffrey T <[email protected]> > Subject: Re: [PATCH net-next 1/3] net: ethtool: add support for forward error > correction modes > [..] > > In our discussions of the above, we decided that we should err in the > > direction of the absolutely simplest abstraction model, even when > > that might result in a failure to establish a link. Our feeling was > > that doing anything else would result in endless user confusion. > > Basically, if it takes longer than a simple paragraph to explain, > > you're probably doing the wrong thing. So, we decided that if a user > > sets up a particular FEC setting, we keep that regardless of conflict > > with different Transceiver Modules. (But flag such issues in the > > System Log in order to try to give the user a chance to understand > > what the new cable they plugged in wasn't working.) > > 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?
This is an interesting dichotomy and we've been trying to resolve it as well as the module variations and permutations grow. I agree with Casey that this bleeds into link speeds as well. I can see both perspectives: try to apply to user settings even if they do something dumb and notify if things go bad; and, swapping modules should reset. Notifications of some kind would help the devices manage this. We tend to go with timers today. Carolyn Carolyn Wyborny Linux Development Networking Division Intel Corporation
