From: Denis Pryazhennikov <Denis.Pryazhennikov@arknetworks.am>
To: dev@dpdk.org
Subject: Clarify FEC capabilities
Date: Fri, 7 Apr 2023 14:16:29 +0400 [thread overview]
Message-ID: <2f32c6ab-1832-cbfc-5675-a63d554a0588@arknetworks.am> (raw)
Hi,
We are currently working on implementing the Forward Error Correction
(FEC) feature in our driver, but we have encountered some difficulties
in understanding the interpretation of the semantics of 'fec_capa', a
bitmask of allowed FEC modes. Specifically, we are unclear about the
meaning of various bit combinations.
In rte_ethdev.h, 'fec_capa' is defined as follows:
```
* @param fec_capa
* A bitmask of allowed FEC modes. If AUTO bit is set, other
* bits specify FEC modes which may be negotiated. If AUTO
* bit is clear, specify FEC modes to be used (only one valid
* mode per speed may be set).
```
We have a few questions regarding this definition:
* Is it possible for the AUTO bit to be set without any other bits?
* Can both RS and BASER bits be set together without the AUTO bit?
Based on our understanding, we have come up with the following
interpretations for different bit combinations:
* NOFEC overrides any other bits, and means "disable all FEC";
* AUTO on its own implies using cable requirements and link partner
autoneg with firmware-default preferences for the cable type;
* AUTO combined with either RS or BASER signifies using the specified
FEC type if the cable and link partner support it; otherwise,
autoneg/firmware-default is used;
* RS or BASER alone means using the specified FEC type if the cable and
link partner support it and either requests it; otherwise, no FEC is
employed;
* Both RS and BASER, with or without AUTO, indicate using FEC if the
cable and link partner support it, preferring RS to BASER.
We would greatly appreciate any assistance in clarifying our
understanding and ensuring that our interpretations are accurate.
Thank you in advance for your help.
Sincerely,
Denis
next reply other threads:[~2023-04-07 10:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 10:16 Denis Pryazhennikov [this message]
2023-04-17 16:05 ` Ferruh Yigit
-- strict thread matches above, loose matches on Subject: below --
2023-04-03 5:01 Denis Pryazhennikov
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=2f32c6ab-1832-cbfc-5675-a63d554a0588@arknetworks.am \
--to=denis.pryazhennikov@arknetworks.am \
--cc=dev@dpdk.org \
/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).