netdev - Re: [RFC PATCH net-next] net: ethtool: add support for forward error correction modes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM5PR12MB1786073763933EAE09E36978C8B40@DM5PR12MB1786.namprd12.prod.outlook.com>
Date:   Tue, 22 Nov 2016 23:30:32 +0000
From:   Casey Leedom <leedom@...lsio.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next] net: ethtool: add support for forward error
 correction modes

  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