[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9BBC4E0CF881AA4299206E2E1412B6265049232F@ORSMSX102.amr.corp.intel.com>
Date: Thu, 6 Jul 2017 22:16:08 +0000
From: "Wyborny, Carolyn" <carolyn.wyborny@...el.com>
To: Casey Leedom <leedom@...lsio.com>, 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>,
"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 Casey Leedom
> Sent: Thursday, July 06, 2017 2:54 PM
> To: Jakub Kicinski <kubakici@...pl>
> 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
>
> | 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.
>
[..]
> 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.
Agree with your points generally, but other networking hw vendors have dealt with this since SFP variant and other modules arrived on the scene.
Powered by blists - more mailing lists