[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9BBC4E0CF881AA4299206E2E1412B62650492000@ORSMSX102.amr.corp.intel.com>
Date: Thu, 6 Jul 2017 21:06:09 +0000
From: "Wyborny, Carolyn" <carolyn.wyborny@...el.com>
To: Jakub Kicinski <kubakici@...pl>, Casey Leedom <leedom@...lsio.com>
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>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: RE: [PATCH net-next 1/3] net: ethtool: add support for forward
error correction modes
> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Jakub Kicinski
> Sent: Thursday, July 06, 2017 12:02 PM
> To: Casey Leedom <leedom@...lsio.com>
> Cc: Dustin Byford <dustin@...ulusnetworks.com>; Andrew Lunn
> <andrew@...n.ch>; Roopa Prabhu <roopa@...ulusnetworks.com>;
> davem@...emloft.net; linville@...driver.com; netdev@...r.kernel.org;
> vidya.chowdary@...il.com; olson@...ulusnetworks.com; Manoj Malviya
> <manojmalviya@...lsio.com>; Santosh Rastapur <santosh@...lsio.com>;
> yuval.mintz@...gic.com; odedw@...lanox.com; ariela@...lanox.com;
> galp@...lanox.com; Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>
> 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
Powered by blists - more mailing lists