On Fri, 28 Jul 2017 23:28:26 -0700, Roopa Prabhu wrote: > On Fri, Jul 28, 2017 at 9:46 AM, Jakub Kicinski <kubak...@wp.pl> wrote: > > On Fri, 28 Jul 2017 07:53:01 -0700, Roopa Prabhu wrote: > >> On Thu, Jul 27, 2017 at 7:33 PM, Jakub Kicinski <kubak...@wp.pl> wrote: > >> > On Thu, 27 Jul 2017 16:47:25 -0700, Roopa Prabhu wrote: > >> >> From: Roopa Prabhu <ro...@cumulusnetworks.com> > >> >> > >> >> 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 FEC encoding control and reporting today is a > >> >> source for interoperability issues for many vendors. > >> >> FEC capability as well as specific FEC mode i.e. Base-R > >> >> or RS modes can be requested or advertised through bits D44:47 of base > >> >> link > >> >> codeword. > >> >> > >> >> This patch set intends to provide option under ethtool to manage and > >> >> report FEC encoding settings for networking devices as per IEEE 802.3 > >> >> bj, bm and by specs. > >> >> > >> >> v2 : > >> >> - minor patch format fixes and typos pointed out by Andrew > >> >> - there was a pending discussion on the use of 'auto' vs > >> >> 'automatic' for fec settings. I have left it as 'auto' > >> >> because in most cases today auto is used in place of > >> >> automatic to represent automatically generated values. > >> >> We use it in other networking config too. I would prefer > >> >> leaving it as auto. > >> > > >> > On the subject of resetting the values when module is replugged I > >> > assume what was previously described remains: > >> > - we always allow users to set the FEC regardless of the module type; > >> > - if user set an incorrect FEC for the module type (or module gets > >> > swapped) the link will be administratively taken down by either > >> > the driver or FW. > >> > > >> > Is that correct? Am I misremembering? > >> > >> yes, correct. And possible future sfp hotplug events can give user-space > >> more info to react to module type changes etc. > > > > OK, if nobody else objects and we go with that - lets make sure we > > document clearly those are expected :) My concern is that if there is > > ever 10G + RS FEC standard we don't want to end up in a situation where > > some drivers silently ignore FEC settings in 10G and other apply it. > > So let's make it clear what the intended Linux behaviour is. It could > > be in the ethtool man page, or the kernel somewhere. > > sure :), ack. We will document it in the ethtool manpage.
Hi Roopa! Did you ever publish the ethtool user space patches at all? I can't find them...