From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7C97842923; Wed, 12 Apr 2023 08:56:53 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 54AC940FAE; Wed, 12 Apr 2023 08:56:53 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id 9230E4014F for ; Mon, 3 Apr 2023 07:01:17 +0200 (CEST) Received: from [192.168.2.238] (unknown [141.136.91.189]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id 241D1E0628 for ; Mon, 3 Apr 2023 09:01:17 +0400 (+04) Message-ID: Date: Mon, 3 Apr 2023 09:01:09 +0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-GB To: dev@dpdk.org From: Denis Pryazhennikov Subject: Clarify FEC capabilities Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 12 Apr 2023 08:56:51 +0200 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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