netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, ecree.xilinx@gmail.com,
	michael.chan@broadcom.com, damian.dybek@intel.com,
	paul.greenwalt@intel.com, rajur@chelsio.com,
	jaroslawx.gawin@intel.com, vkochan@marvell.com, alobakin@pm.me,
	snelson@pensando.io, shayagr@amazon.com, ayal@nvidia.com,
	shenjian15@huawei.com, saeedm@nvidia.com, mkubecek@suse.cz,
	andrew@lunn.ch, roopa@nvidia.com,
	Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next 6/6] ethtool: clarify the ethtool FEC interface
Date: Wed, 24 Mar 2021 18:12:00 -0700	[thread overview]
Message-ID: <20210325011200.145818-7-kuba@kernel.org> (raw)
In-Reply-To: <20210325011200.145818-1-kuba@kernel.org>

The definition of the FEC driver interface is quite unclear.
Improve the documentation.

This is based on current driver and user space code, as well
as the discussions about the interface:

RFC v1 (24 Oct 2016): https://lore.kernel.org/netdev/1477363849-36517-1-git-send-email-vidya@cumulusnetworks.com/
 - this version has the autoneg field
 - no active_fec field
 - none vs off confusion is already present

RFC v2 (10 Feb 2017): https://lore.kernel.org/netdev/1486727004-11316-1-git-send-email-vidya@cumulusnetworks.com/
 - autoneg removed
 - active_fec added

v1 (10 Feb 2017): https://lore.kernel.org/netdev/1486751311-42019-1-git-send-email-vidya@cumulusnetworks.com/
 - no changes in the code

v1 (24 Jun 2017):  https://lore.kernel.org/netdev/1498331985-8525-1-git-send-email-roopa@cumulusnetworks.com/
 - include in tree user

v2 (27 Jul 2017): https://lore.kernel.org/netdev/1501199248-24695-1-git-send-email-roopa@cumulusnetworks.com/

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 include/uapi/linux/ethtool.h | 37 +++++++++++++++++++++++++++++-------
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 517b68c5fcec..f6ef7d42c7a1 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1372,35 +1372,58 @@ struct ethtool_per_queue_op {
 	__u32	cmd;
 	__u32	sub_command;
 	__u32	queue_mask[__KERNEL_DIV_ROUND_UP(MAX_NUM_QUEUE, 32)];
 	char	data[];
 };
 
 /**
- * struct ethtool_fecparam - Ethernet forward error correction(fec) parameters
+ * struct ethtool_fecparam - Ethernet Forward Error Correction parameters
  * @cmd: Command number = %ETHTOOL_GFECPARAM or %ETHTOOL_SFECPARAM
- * @active_fec: FEC mode which is active on the port, GET only.
- * @fec: Bitmask of supported/configured FEC modes
+ * @active_fec: FEC mode which is active on the port, single bit set, GET only.
+ * @fec: Bitmask of configured FEC modes.
  * @reserved: Reserved for future extensions, ignore on GET, write 0 for SET.
+ *
+ * FEC modes supported by the device can be read via %ETHTOOL_GLINKSETTINGS.
+ * FEC settings are configured by link autonegotiation whenever it's enabled.
+ * With autoneg on %ETHTOOL_GFECPARAM can be used to read the current mode.
+ *
+ * When autoneg is disabled %ETHTOOL_SFECPARAM controls the FEC settings.
+ * It is recommended that drivers only accept a single bit set in @fec.
+ * When multiple bits are set in @fec drivers may pick mode in an implementation
+ * dependent way. Drivers should reject mixing %ETHTOOL_FEC_AUTO_BIT with other
+ * FEC modes, because it's unclear whether in this case other modes constrain
+ * AUTO or are independent choices.
+ * Drivers must reject SET requests if they support none of the requested modes.
+ *
+ * If device does not support FEC drivers may use %ETHTOOL_FEC_NONE instead
+ * of returning %EOPNOTSUPP from %ETHTOOL_GFECPARAM.
+ *
+ * See enum ethtool_fec_config_bits for definition of valid bits for both
+ * @fec and @active_fec.
  */
 struct ethtool_fecparam {
 	__u32   cmd;
 	/* bitmask of FEC modes */
 	__u32   active_fec;
 	__u32   fec;
 	__u32   reserved;
 };
 
 /**
  * enum ethtool_fec_config_bits - flags definition of ethtool_fec_configuration
- * @ETHTOOL_FEC_NONE: FEC mode configuration is not supported
- * @ETHTOOL_FEC_AUTO: Default/Best FEC mode provided by driver
+ * @ETHTOOL_FEC_NONE: FEC mode configuration is not supported. Should not
+ *		      be used together with other bits. GET only.
+ * @ETHTOOL_FEC_AUTO: Select default/best FEC mode automatically, usually based
+ *		      link mode and SFP parameters read from module's EEPROM.
+ *		      This bit does _not_ mean autonegotiation.
  * @ETHTOOL_FEC_OFF: No FEC Mode
- * @ETHTOOL_FEC_RS: Reed-Solomon Forward Error Detection mode
- * @ETHTOOL_FEC_BASER: Base-R/Reed-Solomon Forward Error Detection mode
+ * @ETHTOOL_FEC_RS: Reed-Solomon FEC Mode
+ * @ETHTOOL_FEC_BASER: Base-R/Reed-Solomon FEC Mode
+ * @ETHTOOL_FEC_LLRS: Low Latency Reed Solomon FEC Mode (25G/50G Ethernet
+ *		      Consortium)
  */
 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,
-- 
2.30.2


  parent reply	other threads:[~2021-03-25  1:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25  1:11 [PATCH net-next 0/6] ethtool: clarify the ethtool FEC interface Jakub Kicinski
2021-03-25  1:11 ` [PATCH net-next 1/6] ethtool: fec: fix typo in kdoc Jakub Kicinski
2021-03-25 12:06   ` Andrew Lunn
2021-03-25  1:11 ` [PATCH net-next 2/6] ethtool: fec: remove long structure description Jakub Kicinski
2021-03-25 12:07   ` Andrew Lunn
2021-03-25  1:11 ` [PATCH net-next 3/6] ethtool: fec: sanitize ethtool_fecparam->reserved Jakub Kicinski
2021-03-25 12:22   ` Andrew Lunn
2021-03-25 16:02     ` Jakub Kicinski
2021-03-25  1:11 ` [PATCH net-next 4/6] ethtool: fec: sanitize ethtool_fecparam->active_fec Jakub Kicinski
2021-03-25 12:25   ` Andrew Lunn
2021-03-25  1:11 ` [PATCH net-next 5/6] ethtool: fec: sanitize ethtool_fecparam->fec Jakub Kicinski
2021-03-25 12:00   ` Dan Carpenter
2021-03-25 16:03     ` Jakub Kicinski
2021-03-25  1:12 ` Jakub Kicinski [this message]
2021-03-29 11:56   ` [PATCH net-next 6/6] ethtool: clarify the ethtool FEC interface Edward Cree
2021-03-29 12:32     ` Andrew Lunn
2021-03-29 17:39     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210325011200.145818-7-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=alobakin@pm.me \
    --cc=andrew@lunn.ch \
    --cc=ayal@nvidia.com \
    --cc=damian.dybek@intel.com \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=jaroslawx.gawin@intel.com \
    --cc=michael.chan@broadcom.com \
    --cc=mkubecek@suse.cz \
    --cc=netdev@vger.kernel.org \
    --cc=paul.greenwalt@intel.com \
    --cc=rajur@chelsio.com \
    --cc=roopa@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=shayagr@amazon.com \
    --cc=shenjian15@huawei.com \
    --cc=snelson@pensando.io \
    --cc=vkochan@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).