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 D1F6543D50; Tue, 26 Mar 2024 11:30:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BEA514028B; Tue, 26 Mar 2024 11:30:31 +0100 (CET) Received: from wfout8-smtp.messagingengine.com (wfout8-smtp.messagingengine.com [64.147.123.151]) by mails.dpdk.org (Postfix) with ESMTP id C83F740265 for ; Tue, 26 Mar 2024 11:30:30 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.west.internal (Postfix) with ESMTP id C2E2E1C000C8; Tue, 26 Mar 2024 06:30:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 26 Mar 2024 06:30:27 -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=1711449025; x=1711535425; bh=vebsxpQbeQtXtSF1l15/IMyVR1e3CSktvmifqPu5wIE=; b= VUuJMSNcD/87fBeCz+QPoN4bcZSJhGifJ8Q5h3Y4NDcBGhGlrOuvxakCPcoes/Hw k9yuh5uWnA7VNWwhXrRnGQew2jRJKzzcvYg5HLO773d4R4QYnwxHLKB7CRoel3bA mfcVjsZW4Tq9MDJ8O/mPyaupqS+dr+5JDlZnZnG/cdl6I/LVLSIWkDG/sNhy60r0 XcWsiCH/riKJODhBJq3114/LIHdX8/Je7WseNGOX+/o6mWrhhD9D2ZGAbhyF6hel m1kTaYyyh0MY/tB/Bl8DhG016KzZlrXvGIfqBdMgLCRbDKr5FvyThOPGddewxq94 weSGdsBKx8XV6nulfZeAfA== 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=1711449025; x= 1711535425; bh=vebsxpQbeQtXtSF1l15/IMyVR1e3CSktvmifqPu5wIE=; b=m yMskbhQ3B97gntvxzHaMBH30ML4i9SlSaG5TRN3fbL8PhiaL+I/FSvbP6fZgC0Op ANLF52knGpu8r+lrXkOlIdLHxov37qWKfVN85z54/rFpAQ0AWLzUKDS7K8dRsFtu YPSUGOmHfgE7V3L7tzL6+X2ZKb1mLHMxV4G8ltOfE/cyu9a6hQWnyyPJpjLrqmvm GWisp67mnt/W5Ve0Nj3NpCQlX4A79StDMpmhxkA8ncu5ue7INNOQH+HaFVPgY0qN vn8wEkA3f8YyjRfq87TTYRzNFOqypArDC2Lhr3n3PT2gBq3VHe5b6GLl8z1qderA 2afZS8+3321XU8bevYvow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddufedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpefftdeuhfehvdekleelveffvdelhfelhedvgedtvddvudeuieev tdfgjedvudegfeenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Mar 2024 06:30:22 -0400 (EDT) From: Thomas Monjalon To: huangdengdui , Damodharam Ammepalli , "lihuisong (C)" 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, stephen@networkplumber.org, jerinjacobk@gmail.com, liuyonglong@huawei.com, fengchengwen@huawei.com, haijie1@huawei.com Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes Date: Tue, 26 Mar 2024 11:30:18 +0100 Message-ID: <3628913.0YcMNavOfZ@thomas> In-Reply-To: <68ee0a54-c0b4-293c-67ee-efed8964c33b@huawei.com> References: <20240312075238.3319480-4-huangdengdui@huawei.com> <3325989.AxlXzFCzgd@thomas> <68ee0a54-c0b4-293c-67ee-efed8964c33b@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 26/03/2024 02:42, lihuisong (C): >=20 > =E5=9C=A8 2024/3/25 17:30, Thomas Monjalon =E5=86=99=E9=81=93: > > 25/03/2024 07:24, huangdengdui: > >> 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 Gbp= s */ > >>>> +#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbp= s 2lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbp= s */ > >>>> +#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 Gbp= s 4lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 Gbp= s */ > >>>> +#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 Gbp= s 4lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_100G RTE_BIT32(14) /**< 100 Gb= ps */ > >>>> +#define RTE_ETH_LINK_SPEED_200G RTE_BIT32(15) /**< 200 Gb= ps 4lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_400G RTE_BIT32(16) /**< 400 Gb= ps 4lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_10G_4LANES RTE_BIT32(17) /**< 10 Gb= ps 4lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_50G_2LANES RTE_BIT32(18) /**< 50 Gbp= s 2 lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_100G_2LANES RTE_BIT32(19) /**< 100 Gb= ps 2 lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_100G_4LANES RTE_BIT32(20) /**< 100 Gb= ps 4lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_200G_2LANES RTE_BIT32(21) /**< 200 Gb= ps 2lanes */ > >>>> +#define RTE_ETH_LINK_SPEED_400G_8LANES RTE_BIT32(22) /**< 400 Gb= ps 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 l= anes 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 lane= s. > >> > >> 2. For the PHY, When the physical layer capability is configured throu= gh 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 > >> > >> 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 versio= n. > >> 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. > > 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 h= andle > > in some get/set style functions. > Having a separate and simple API is cleaner. It's good. > But supported lane capabilities have a lot to do with the specified=20 > speed. This is determined by releated specification. > If we add a separate API for speed lanes, it probably is hard to check=20 > the validity of the configuration for speed and lanes. > And the setting lane API sepparated from speed is not good for=20 > uniforming all PMD's behavior in ethdev layer. Please let's be more specific. There are 3 needs: - set PHY lane config - get PHY lane config - get PHY lane capabilities There is no problem providing a function to get the number of PHY lanes. It is possible to set PHY lanes number after defining a fixed speed. > The patch[1] is an example for this separate API. > I think it is not very good. It cannot tell user and PMD the follow point= s: > 1) user don't know what lanes should or can be set for a specified speed= =20 > on one NIC. This is about capabilities. Can we say a HW will support a maximum number of PHY lanes in general? We may need to associate the maximum speed per lane? Do we really need to associate PHY lane and PHY speed numbers for capabilit= ies? Example: if a HW supports 100G-4-lanes and 200G-2-lanes, may we assume it is also supporting 200G-4-lanes? > 2) how should PMD do for a supported lanes in their HW? I don't understand this question. Please rephrase. > Anyway, if we add setting speed lanes feature, we must report and set=20 > speed and lanes capabilities for user well. > otherwise, user will be more confused. Well is not necessarily exposing all raw combinations as ethtool does. > [1] https://patchwork.dpdk.org/project/dpdk/list/?series=3D31606