DPDK patches and discussions
 help / color / mirror / Atom feed
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


             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).