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 7360143D46; Mon, 25 Mar 2024 10:30:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F346D40271; Mon, 25 Mar 2024 10:30:34 +0100 (CET) Received: from wfhigh8-smtp.messagingengine.com (wfhigh8-smtp.messagingengine.com [64.147.123.159]) by mails.dpdk.org (Postfix) with ESMTP id 5A94B40270 for ; Mon, 25 Mar 2024 10:30:33 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.west.internal (Postfix) with ESMTP id B1B4218000B8; Mon, 25 Mar 2024 05:30:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 25 Mar 2024 05:30:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1711359030; x=1711445430; bh=bJigcezFyqjcLGSJZi5UU4J5EXq25Tjp0frLvgUkdzA=; b= ldnS2m2sfs2DQr+FRaE2UpzR/ugYaYnEiwuNszc0XOdmSJ2dWeyXoVMzFxf4LP4r YGEuHUZnoo/INSycp4yRxlNWuXf/2mnIaH+m1/mDF80OGtDFrXexjq1106NxymJy diNzkDN8Q/sRDILRHo1tbCgvlVxluJjSHEvtsrTViGtrJDMVzrQVWmNlwZ9HtX3m iYwqO6I3IHkPQtWB4fWZhTL+Jp9NX54AWs8zXxCM+SMnzCXxiICLrTGFSpoHW9SP VKYbBvaNq6iCza4MWOK1qjcuK1qzZSKAJ+HqgUqn4AfR51Aefj9GuCdaujQQUe3z qzvVjkHrCFVEXmEfVW8qXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711359030; x= 1711445430; bh=bJigcezFyqjcLGSJZi5UU4J5EXq25Tjp0frLvgUkdzA=; b=g KJCLZBDU63LPwkLP4EEe3JcqP5D4LsUA+IrxMYnAY2i7jw7faXOn9WVL0ph1dYZc iQKZe78T+osd7OB2msX1VqrlVAfPUi7BduvkLCv1MPWctzducGqUcMotATCEpvYg 0f9V6+MhFriHUAkwd8YT6pBMIyIife9r87Df190qiIxz1GenNQ/oLlyIq5YiYkBc hKsY8m8a3tAxc26vgXu1a+fMrgU/2Tz2pH22yi5s5D8qMymE6wuBIAnGTQZzbZhG y7uZAusBJk2arvzjgQOYJTMgRQ4RJjh9JUS2hPh8aiP8CyrXQYZ2j24mIjEEDq4S Na8lL5OJR3MxiOvzTtZnw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddtledgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 Mar 2024 05:30:27 -0400 (EDT) From: Thomas Monjalon To: huangdengdui Cc: ajit.khaparde@broadcom.com, roretzla@linux.microsoft.com, Damodharam Ammepalli , dev@dpdk.org, ferruh.yigit@amd.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru, damodharam.ammepalli@broadcom.com, stephen@networkplumber.org, jerinjacobk@gmail.com, liuyonglong@huawei.com, fengchengwen@huawei.com, haijie1@huawei.com, lihuisong@huawei.com Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes Date: Mon, 25 Mar 2024 10:30:25 +0100 Message-ID: <3325989.AxlXzFCzgd@thomas> In-Reply-To: <90a508af-7b6d-4026-b4e9-ec35c0df9b97@huawei.com> References: <20240312075238.3319480-4-huangdengdui@huawei.com> <4413054.MSiuQNM8U4@thomas> <90a508af-7b6d-4026-b4e9-ec35c0df9b97@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 25/03/2024 07:24, huangdengdui: >=20 > 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 */ > >=20 > > 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 lan= es separated. > > Can we have lanes information a separate value? no need for bitmask. > >=20 > Hi,Thomas, Ajit, roretzla, damodharam >=20 > 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 >=20 > Therefore, users are more accustomed to the coupling of speed and lanes. >=20 > 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=E2=80=937=E2=80=94PMA/PMD control 2 register bit definitions[1] > PMA/PMD type selection > 1 0 0 1 0 1 0 =3D 100GBASE-SR2 PMA/PMD > 0 1 0 1 1 1 1 =3D 100GBASE-SR4 PMA/PMD >=20 > Therefore, coupling speeds and lanes is easier to understand. > And it is easier for the driver to report the support lanes. >=20 > In addition, the code implementation is compatible with the old version. > When the driver does not support the lanes setting, the code does not nee= d to be modified. >=20 > So I think the speed and lanes coupling is better. I don't think so. You are mixing hardware implementation, user tool, and API. Having a separate and simple API is cleaner and not more difficult to handle in some get/set style functions.