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 70753A034F; Mon, 29 Mar 2021 13:44:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E7DB3406B4; Mon, 29 Mar 2021 13:44:14 +0200 (CEST) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by mails.dpdk.org (Postfix) with ESMTP id 5C46B40042 for ; Mon, 29 Mar 2021 13:44:13 +0200 (CEST) Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4F89fs5NRtzlW2n; Mon, 29 Mar 2021 19:42:29 +0800 (CST) Received: from [10.66.74.184] (10.66.74.184) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Mon, 29 Mar 2021 19:44:07 +0800 To: Thomas Monjalon CC: , , , , References: <2a9f3c44-44da-854b-8b25-772a3570baa4@huawei.com> <9105928.7imIDBDKWL@thomas> <7245184.973KLNHvPo@thomas> From: Huisong Li Message-ID: <6db25f2c-3f87-d444-bfdf-530bdf7c87f8@huawei.com> Date: Mon, 29 Mar 2021 19:44:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <7245184.973KLNHvPo@thomas> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.66.74.184] X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] Questions about reporting auto-negotiation capability 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 Sender: "dev" 在 2021/3/29 15:19, Thomas Monjalon 写道: > 29/03/2021 09:03, Thomas Monjalon: >> 29/03/2021 06:02, Huisong Li: >>> 'speed_capa' in struct rte_eth_dev_info is defined as follows: >>> >>> uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ >>> >>> >>> Most PMD drivers use this field to report the speeds capability >>> supported by the device to the upper-layer app. >>> >>> But it seems that few NICs report their auto-negotiation capability >>> through this field. If NIC also uses it to report >>> their auto-negotiation capability through this field, and should set it >>> to ETH_LINK_SPEED_AUTONEG(0) based on >>> the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the >>> report of the speeds capability . >>> >>> I don't know how to correctly report the auto-negotiation capability of >>> the device. Thanks for your reply. >> ETH_LINK_SPEED_AUTONEG is not for capabilities. >> Anyway, if it is set, it changes nothing (0) in the bitmap. >> I see mlx5 is wrongly using it. >> >> speed_capa is only for enumerating speeds. > I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa > if the device cannot support autonegotiation. > Should we add a note in doxygen? Can we use bit 0 to indicate whether the device supports auto-negotiation? Like, 1/ If device doesn't support auto-negotiation, set bit(0) of the 'speed_capa' to 1, namely, "speed_capa |= ETH_LINK_SPEED_FIXED". 2/ Other bits of the 'speed_capa' report all the speed capabilities supported by the device regardless of the value of bit(0) . The above behavior is similar to cxgbe, bnxt, and mlx5. In this way, users can know whether the device supports auto-negotiation based on bit(0) and detect the supported speed capabilities based on other bits. After all, this 'speed_capa' and the 'link_speeds' in "rte_eth_conf" struct have different purposes. > > > .