Andrew Lunn wrote:
> And when we are talking about SFP modules, we are not talking about
> somebody who can just about boiling an egg and put bread in the
> toaster.
>
> Anybody using these SFP modules knows a lot about networking, is a
> power user, and probably does not rely on plug and pray.
> If you choose to think of a cable unplug/plug event as "hot plug", then
> the "reset" is the model that feels right. But I'll note that this is also
> presupposing what the right model is for users. This is akin
> to trying to decide what to make for dinner and deciding that a
> hammer is the r
| From: Andrew Lunn
| Sent: Thursday, July 6, 2017 4:15 PM
|
| > Even this feels too extreme for me. I think users would hate it. They
| > did an ifup and swapped cables. They expect the OS/Driver/Firmware
| > to continue trying to honor their ifup request.
|
| Lets take a look around at
On Fri, 7 Jul 2017 01:15:50 +0200, Andrew Lunn wrote:
> > Even this feels too extreme for me. I think users would hate it. They
> > did an ifup and swapped cables. They expect the OS/Driver/Firmware
> > to continue trying to honor their ifup request.
>
> Lets take a look around at other subsy
> Even this feels too extreme for me. I think users would hate it. They
> did an ifup and swapped cables. They expect the OS/Driver/Firmware
> to continue trying to honor their ifup request.
Lets take a look around at other subsystems
What happens if you hot-unplug a SATA drive?
An MMC car
| From: Jakub Kicinski
| Sent: Thursday, July 6, 2017 3:43 PM
|
| On Thu, 6 Jul 2017 21:53:46 +, Casey Leedom wrote:
| >
| > 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 las
| From: Andrew Lunn
| Sent: Thursday, July 6, 2017 3:33 PM
|
| On Thu, Jul 06, 2017 at 09:53:46PM +, Casey Leedom wrote:
| >
| > 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
On Thu, 6 Jul 2017 21:53:46 +, Casey Leedom wrote:
> | From: Jakub Kicinski
> | 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 s
| From: Wyborny, Carolyn
| Sent: Thursday, July 6, 2017 3:16 PM
|
| Agree with your points generally, but other networking hw vendors have
| dealt with this since SFP variant and other modules arrived on the scene.
The only case of this of which I'm aware is the SFP+ RJ45 1Gb/s
Transceiver Modu
> Agree with your points generally, but other networking hw vendors
> have dealt with this since SFP variant and other modules arrived on
> the scene.
It seems like there is interest now in consolidating this, in the same
way that copper PHYs got consolidated. Yes, there are some MAC drivers
which
On Thu, Jul 06, 2017 at 09:53:46PM +, Casey Leedom wrote:
> | From: Jakub Kicinski
> | 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 intr
; linvi...@tuxdriver.com; netdev@vger.kernel.org;
> vidya.chowd...@gmail.com; ol...@cumulusnetworks.com; Manoj Malviya
> ; Santosh Rastapur ;
> yuval.mi...@qlogic.com; od...@mellanox.com; ari...@mellanox.com;
> g...@mellanox.com; Kirsher, Jeffrey T
> Subject: Re: [PATCH net-next 1/3] net:
| From: Jakub Kicinski
| 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 ca
; linvi...@tuxdriver.com; netdev@vger.kernel.org;
> vidya.chowd...@gmail.com; ol...@cumulusnetworks.com; Manoj Malviya
> ; Santosh Rastapur ;
> yuval.mi...@qlogic.com; od...@mellanox.com; ari...@mellanox.com;
> g...@mellanox.com; Kirsher, Jeffrey T
> Subject: Re: [PATCH net-next 1/3
On Thu, 6 Jul 2017 18:53:42 +, Casey Leedom wrote:
> However, the first question which pops up is: what happens if a user
> explicitly selects a particular FEC for from the set offered by the
> current Transceiver Module, and then swap out Transceiver Modules to
> one which doesn't support that
| From: Jakub Kicinski
| Sent: Wednesday, June 28, 2017 6:00 PM
|
| On Wed, 28 Jun 2017 14:47:51 -0700, Dustin Byford wrote:
| >
| > You're not the first, or the second to ask that question. I agree it
| > could use clarification.
| >
| > I always read auto in this context as automatic rat
> Hi Gal,
>
> ...
>> What is the difference between the information in ethtool DEVNAME and
>> ethtool --show-fec DEVNAME?
> I think there are two questions there. First, how does the FEC-related
> information from glinksettings differ from what's retrieved via
> gfecparam. Second, how is that ex
On Wed, Jun 28, 2017 at 02:47:51PM -0700, Dustin Byford wrote:
> Hi Andrew,
>
> On Wed Jun 28 15:41, Andrew Lunn wrote:
> > On Tue, Jun 27, 2017 at 03:22:39AM -0700, Jakub Kicinski wrote:
> > > On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > > > Encoding: Types of encoding
> > > > Off
On Wed, 28 Jun 2017 14:47:51 -0700, Dustin Byford wrote:
> Hi Andrew,
>
> On Wed Jun 28 15:41, Andrew Lunn wrote:
> > On Tue, Jun 27, 2017 at 03:22:39AM -0700, Jakub Kicinski wrote:
> > > On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > > > Encoding: Types of encoding
> > > > Off
Hi Andrew,
On Wed Jun 28 15:41, Andrew Lunn wrote:
> On Tue, Jun 27, 2017 at 03:22:39AM -0700, Jakub Kicinski wrote:
> > On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > > Encoding: Types of encoding
> > > Off: Turning off any encoding
> > > RS : enforcing RS-FEC encoding on s
On Tue, Jun 27, 2017 at 03:22:39AM -0700, Jakub Kicinski wrote:
> On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > Encoding: Types of encoding
> > Off: Turning off any encoding
> > RS : enforcing RS-FEC encoding on supported speeds
> > BaseR : enforcing Base R encoding on sup
On Tue, 27 Jun 2017 23:27:34 -0700, Dustin Byford wrote:
> On Tue Jun 27 03:22, Jakub Kicinski wrote:
> > On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > > Encoding: Types of encoding
> > > Off: Turning off any encoding
> > > RS : enforcing RS-FEC encoding on supported speed
Hi Jakub,
On Tue Jun 27 03:22, Jakub Kicinski wrote:
> On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> > Encoding: Types of encoding
> > Off: Turning off any encoding
> > RS : enforcing RS-FEC encoding on supported speeds
> > BaseR : enforcing Base R encoding on supported spe
Hi Gal,
On Sun Jun 25 16:38, Gal Pressman wrote:
>
> > ...
> >
> > SHOW FEC option:
> > root@tor: ethtool --show-fec swp1
> > FEC parameters for swp1:
> > Active FEC encodings: RS
> > Configured FEC encodings: RS | BaseR
> >
> > ETHTOOL DEVNAME output modification:
> >
> > ethtool devname outpu
On Sat, 24 Jun 2017 12:19:43 -0700, Roopa Prabhu wrote:
> Encoding: Types of encoding
> Off: Turning off any encoding
> RS : enforcing RS-FEC encoding on supported speeds
> BaseR : enforcing Base R encoding on supported speeds
> Auto : IEEE defaults for the speed/medium combination
> ...
>
> SHOW FEC option:
> root@tor: ethtool --show-fec swp1
> FEC parameters for swp1:
> Active FEC encodings: RS
> Configured FEC encodings: RS | BaseR
>
> ETHTOOL DEVNAME output modification:
>
> ethtool devname output:
> root@tor:~# ethtool swp1
> Settings for swp1:
> root@hpe-7712-03:~# e
From: Vidya Sagar Ravipati
Forward Error Correction (FEC) modes i.e Base-R
and Reed-Solomon modes are introduced in 25G/40G/100G standards
for providing good BER at high speeds. Various networking devices
which support 25G/40G/100G provides ability to manage supported FEC
modes and the lack of FE
27 matches
Mail list logo
