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 speeds > > > BaseR : enforcing Base R encoding on supported speeds > > > Auto : IEEE defaults for the speed/medium combination > > > > Just to be sure - does auto mean autonegotiate as defined by IEEE or > > some presets? IIUC there is a notion of different length cables > > defaulting to different strength of FEC in 25GE? > > In this context, "auto" doesn't mean autoneg. Typically, if it's a > copper (CR) link autoneg has taken care of the FEC settings. If you're > using sfecparam, you're probably dealing with optics where there is no > real autoneg. > > Here, the term "auto", in its simplest implementation, would mean the > driver picks a preset based on the speed, cable (typically an SFF > cable), and hardware capability. "IEEE defaults" in the comment refers > to a couple of tables you'll find in IEEE specs (sorry I can't dig them > up at the moment) that suggest FEC modes based on speed, medium > (CR/SR/LR) and perhaps length in the CR case. So, yes, perhaps length > is part of the calculation for the appropriate "auto" mode. This is > essentially why this patch set is important. Drivers up until now can > be thought of as implementing "auto". Sometimes that matches the > expectation of a link partner, especially if both sides support the > "IEEE defaults", but it's somewhat common for there to be a mismatch. > That can be because one side isn't using the "IEEE default" FEC mode for > the speed/medium/length, but it can also be because the hardware doesn't > support the most common FEC mode for a speed/medium/length. We need a > way to explicitly set the FEC mode. But, the hope is that "auto" is a > reasonable default.
Thanks for the explanation!
