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.
