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 BDCC143D42; Mon, 25 Mar 2024 07:24:40 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4539D402AF; Mon, 25 Mar 2024 07:24:40 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 2060740270 for ; Mon, 25 Mar 2024 07:24:37 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4V32rv4RQxzXjj2; Mon, 25 Mar 2024 14:21:51 +0800 (CST) Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84]) by mail.maildlp.com (Postfix) with ESMTPS id 6DAE418007C; Mon, 25 Mar 2024 14:24:35 +0800 (CST) Received: from [10.67.121.193] (10.67.121.193) by dggpeml500011.china.huawei.com (7.185.36.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 25 Mar 2024 14:24:35 +0800 Message-ID: <90a508af-7b6d-4026-b4e9-ec35c0df9b97@huawei.com> Date: Mon, 25 Mar 2024 14:24:34 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes To: Thomas Monjalon , , , Damodharam Ammepalli CC: , , , , , , , , , , , References: <20240312075238.3319480-4-huangdengdui@huawei.com> <20240322070923.244417-1-huangdengdui@huawei.com> <20240322070923.244417-2-huangdengdui@huawei.com> <4413054.MSiuQNM8U4@thomas> Content-Language: en-US From: huangdengdui In-Reply-To: <4413054.MSiuQNM8U4@thomas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.193] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500011.china.huawei.com (7.185.36.84) 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 On 2024/3/22 21:58, Thomas Monjalon wrote: > 22/03/2024 08:09, Dengdui Huang: >> -#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 Gbps */ >> -#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbps */ >> -#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbps */ >> -#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 Gbps */ >> -#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 Gbps */ >> -#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 Gbps */ >> -#define RTE_ETH_LINK_SPEED_100G RTE_BIT32(14) /**< 100 Gbps */ >> -#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< 200 Gbps */ >> -#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< 400 Gbps */ >> +#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 Gbps */ >> +#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbps 2lanes */ >> +#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbps */ >> +#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 Gbps 4lanes */ >> +#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 Gbps */ >> +#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 Gbps 4lanes */ >> +#define RTE_ETH_LINK_SPEED_100G RTE_BIT32(14) /**< 100 Gbps */ >> +#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< 200 Gbps 4lanes */ >> +#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< 400 Gbps 4lanes */ >> +#define RTE_ETH_LINK_SPEED_10G_4LANES RTE_BIT32(17) /**< 10 Gbps 4lanes */ >> +#define RTE_ETH_LINK_SPEED_50G_2LANES RTE_BIT32(18) /**< 50 Gbps 2 lanes */ >> +#define RTE_ETH_LINK_SPEED_100G_2LANES RTE_BIT32(19) /**< 100 Gbps 2 lanes */ >> +#define RTE_ETH_LINK_SPEED_100G_4LANES RTE_BIT32(20) /**< 100 Gbps 4lanes */ >> +#define RTE_ETH_LINK_SPEED_200G_2LANES RTE_BIT32(21) /**< 200 Gbps 2lanes */ >> +#define RTE_ETH_LINK_SPEED_400G_8LANES RTE_BIT32(22) /**< 400 Gbps 8lanes */ > > I don't think it is a good idea to make this more complex. > It brings nothing as far as I can see, compared to having speed and lanes separated. > Can we have lanes information a separate value? no need for bitmask. > Hi,Thomas, Ajit, roretzla, damodharam I also considered the option at the beginning of the design. But this option is not used due to the following reasons: 1. For the user, ethtool couples speed and lanes. The result of querying the NIC capability is as follows: Supported link modes: 100000baseSR4/Full 100000baseSR2/Full The NIC capability is configured as follows: ethtool -s eth1 speed 100000 lanes 4 autoneg off ethtool -s eth1 speed 100000 lanes 2 autoneg off Therefore, users are more accustomed to the coupling of speed and lanes. 2. For the PHY, When the physical layer capability is configured through the MDIO, the speed and lanes are also coupled. For example: Table 45–7—PMA/PMD control 2 register bit definitions[1] PMA/PMD type selection 1 0 0 1 0 1 0 = 100GBASE-SR2 PMA/PMD 0 1 0 1 1 1 1 = 100GBASE-SR4 PMA/PMD Therefore, coupling speeds and lanes is easier to understand. And it is easier for the driver to report the support lanes. In addition, the code implementation is compatible with the old version. When the driver does not support the lanes setting, the code does not need to be modified. So I think the speed and lanes coupling is better. [1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9844436