On Fri, Jul 28, 2017 at 10:29 AM, Andrew Lunn <and...@lunn.ch> wrote: > On Fri, Jul 28, 2017 at 09:46:20AM -0700, Jakub Kicinski 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. > > You might also find this interesting: > > https://py3.patchwork.dja.id.au/patch/42846/ > > Most of the rest of the series has been reviewed, so i don't think it > will be too long before it is in the kernel. >
yes, we are excited about this work as well..
