I'm attempting to start the work necessary to implement Vidya's proposed new
ethtool interface to manage Forward Error Correction settings on a link. I'm
confused by the ethtool FEC API and the degree/type of control it offers. At
the top of the patch we have:
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 : Default FEC settings for divers , and would represent
asking the hardware to essentially go into a best effort mode.
but then later on we have:
+struct ethtool_fecparam {
+ __u32 cmd;
+ __u32 autoneg;
+ /* bitmask of FEC modes */
+ __u32 fec;
+ __u32 reserved;
+};
...
+enum ethtool_fec_config_bits {
+ ETHTOOL_FEC_NONE_BIT,
+ ETHTOOL_FEC_AUTO_BIT,
+ ETHTOOL_FEC_OFF_BIT,
+ ETHTOOL_FEC_RS_BIT,
+ ETHTOOL_FEC_BASER_BIT,
+};
...
+ ETHTOOL_LINK_MODE_FEC_NONE_BIT = 47,
+ ETHTOOL_LINK_MODE_FEC_RS_BIT = 48,
+ ETHTOOL_LINK_MODE_FEC_BASER_BIT = 49,
The last ethtool Link Mode bits seem to imply a separable FEC on/off with
individual control for RS and BASER. How would the "Auto" from the top be
encoded within these Link Mode bits? And I don't see any reference to the
ethtool_fec_config_bits in the kernel or ethtool patches so I'm not sure what
they're supposed to reference. Can you clarify the above? I.e. can you offer
a small template example of what a driver implementation might look like
interpreting the incoming Link Mode Bits?
And do we expect that there will be new FECs in the future?
Casey
