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 DC96143CFF; Fri, 22 Mar 2024 14:51:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7560E402A7; Fri, 22 Mar 2024 14:51:28 +0100 (CET) Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com [103.168.172.150]) by mails.dpdk.org (Postfix) with ESMTP id 0E5C840284 for ; Fri, 22 Mar 2024 14:51:27 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id 44A911380077; Fri, 22 Mar 2024 09:51:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 22 Mar 2024 09:51:26 -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=1711115486; x=1711201886; bh=Ew3jC1NwPq26Bhwimru0wQzBZZrUzaTIrd0sjihTy5A=; b= jkd/7cQfg0kQu25G+Xvb/1Bjd6tmBhXDUzu2Udi3npgmezcoyegsXGO05vzmGPjB 58hp1I7hHpCYlNgfXqGbjJHdBCDVqPbsuZx8hYV4m92M1sc+6etD/7sL2jvMSISV speZykgFLXuljoPVk8I0jE1moOX4RWXjZrcZPnUkA9qHEyU0cu9mZElxV5HhvHgK F1xUB6AdacusqS8HtJF2qS0uRaQcG8bFPxyaVZF9YbSNP6pF6uBVhz587y1xgid6 uep9RaqtZxXmqhByj8WxyyQjQke3Ri9k6zAwQ5uPLdyXxdWLmFD72kHhajeAEtjt AHy9a8iBl++m9Z7wRsHuyA== 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=1711115486; x= 1711201886; bh=Ew3jC1NwPq26Bhwimru0wQzBZZrUzaTIrd0sjihTy5A=; b=Z EwL1ed/2oM59VLrESWtVTuFNJ0UtmF0CIbyPOpM27SekPxM5d3hIXOaKALeGnxYL 6W3OpxMfg8Y69x6qeC35RR9ClOU89mgYbuMv3BMVRZedhKHDod3gei3W4ZbQbepv LQ60yrGNSPaL89qDYwYF3hhHi/9UWRU4UKjQHQWEPC6x12yzF0x14mJ8CmzZtzPO wySwSY5rf+gaQaxm/WqZQH7LJ+9o73VmgqHS54b/vOZv7wHT3Y8k7Pxb0CWyLmL4 Kct4A4aWxY7JjExA9SAXVYGF2O+544Sujde8B2djJRD3DM/R9Y/utLMNZevtLNpC d33dHNCsfNwYzWBReRrJw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddttddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Mar 2024 09:51:23 -0400 (EDT) From: Thomas Monjalon To: Ajit Khaparde , Jerin Jacob Cc: huangdengdui , Damodharam Ammepalli , Ferruh Yigit , dev@dpdk.org, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru, liuyonglong@huawei.com, fengchengwen@huawei.com, haijie1@huawei.com, lihuisong@huawei.com Subject: Re: [PATCH 0/3] support setting lanes Date: Fri, 22 Mar 2024 14:51:21 +0100 Message-ID: <16615733.hlxOUv9cDv@thomas> In-Reply-To: References: <20240312075238.3319480-1-huangdengdui@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 22/03/2024 06:51, Jerin Jacob: > On Fri, Mar 22, 2024 at 10:56=E2=80=AFAM Ajit Khaparde > wrote: > > > > On Thu, Mar 21, 2024 at 9:39=E2=80=AFPM Jerin Jacob wrote: > > > > > > On Fri, Mar 22, 2024 at 7:58=E2=80=AFAM huangdengdui wrote: > > > > > > > > > > > > > > > > On 2024/3/21 16:28, Thomas Monjalon wrote: > > > > > 21/03/2024 03:02, huangdengdui: > > > > >> > > > > >> On 2024/3/20 20:31, Ferruh Yigit wrote: > > > > >>> On 3/18/2024 9:26 PM, Damodharam Ammepalli wrote: > > > > >>>> On Mon, Mar 18, 2024 at 7:56=E2=80=AFAM Thomas Monjalon wrote: > > > > >>>>> > > > > >>>>> 12/03/2024 08:52, Dengdui Huang: > > > > >>>>>> Some speeds can be achieved with different number of lanes. = =46or example, > > > > >>>>>> 100Gbps can be achieved using two lanes of 50Gbps or four la= nes of 25Gbps. > > > > >>>>>> When use different lanes, the port cannot be up. > > > > >>>>> > > > > >>>>> I'm not sure what you are referring to. > > > > >>>>> I suppose it is not PCI lanes. > > > > >>>>> Please could you link to an explanation of how a port is spli= t in lanes? > > > > >>>>> Which hardware does this? > > > > >>>>> > > > > >>>> This is a snapshot of 100Gb that the latest BCM576xx supports. > > > > >>>> 100Gb (NRZ: 25G per lane, 4 lanes) link speed > > > > >>>> 100Gb (PAM4-56: 50G per lane, 2 lanes) link speed > > > > >>>> 100Gb (PAM4-112: 100G per lane, 1 lane) link speed > > > > >>>> > > > > >>>> Let the user feed in lanes=3D< integer value> and the NIC driv= er decides > > > > >>>> the matching combination speed x lanes that works. In future i= f a new speed > > > > >>>> is implemented with more than 8 lanes, there wouldn't be a need > > > > >>>> to touch this speed command. Using separate lane command would > > > > >>>> be a better alternative to support already shipped products an= d only new > > > > >>>> drivers would consider this lanes configuration, if applicable. > > > > >>>> > > > > >>> > > > > >>> As far as I understand, lane is related to the physical layer o= f the > > > > >>> NIC, there are multiple copies of transmitter, receiver, modula= tor HW > > > > >>> block and each set called as a 'lane' and multiple lanes work t= ogether > > > > >>> to achieve desired speed. (please correct me if this is wrong). > > > > >>> > > > > >>> Why not just configuring the speed is not enough? Why user need= s to know > > > > >>> the detail and configuration of the lanes? > > > > >>> Will it work if driver/device configure the "speed x lane" inte= rnally > > > > >>> for the requested speed? > > > > >>> > > > > >>> Is there a benefit to force specific lane count for a specific = speed > > > > >>> (like power optimization, just a wild guess)? > > > > >>> > > > > >>> > > > > >>> And +1 for auto-negotiation if possible. > > > > >> > > > > >> As you said above,=EF=BC=8Cmultiple lanes work together to achie= ve desired speed. > > > > >> For example, the following solutions can be used to implement 10= 0G: > > > > >> 1=E3=80=81Combines four 25G lanes > > > > >> 2=E3=80=81Combines two 50G lanes > > > > >> 3=E3=80=81A single 100G lane > > > > >> > > > > >> It is assumed that two ports are interconnected and the two port= s support > > > > >> the foregoing three solutions. But, we just configured the speed= to 100G and > > > > >> one port uses four 25G lanes by default and the other port uses = two 50G lanes > > > > >> by default, the port cannot be up. In this case, we need to conf= igure the > > > > >> two ports to use the same solutions (for example, uses two 50G l= anes) > > > > >> so that the ports can be up. > > > > > > > > > > Why this config is not OK? How do we know? > > > > > Really I have a very bad feeling about this feature. > > > > > > > > > > > > > > Sorry, I don't quite understand your question. > > > > Are you asking why cannot be up when one port uses four 25G lanes a= nd the other port uses two 50G lanes? > > > > > > > > 100GBASE-SR2 (two 50G lanes) and 100GBASE-SR4 (four 25G lanes) have= different standards at the physical layer.[1] > > > > So it's not possible to communicate. Configuring lanes can help the= driver choose the same standard. > > > > > > Typically, low-level drivers like FW configure this. > > > > > > For example, If FW configures, 100G port as 100GBASE-SR2 then two > > > ethdev(port 0 and port1) will show up. > > > Now, assume if we expose this API and Can end user configure port 1 as > > > 25G lines if so, > > > a) What happens to port0 and it states? > > There should be no impact to port0. > > > > > b) Will port2, port3 will show up after issuing this API(As end user > > > configured 25Gx4 for 100G)? Will application needs to hotplug to get > > > use ports. > > No. The port count does not change. Nor does the number of PCI > > functions seen by the host. Unless designed otherwise. > > > > Changing the lane count does not change anything in physical terms. > > What changes is the modulation or the signaling scheme. > > The number of lanes which can be supported is determined by > > the PHY itself and the cables used and needs to be negotiated appropria= tely > > with the remote partner - which is just like using forced Ethernet Speed > > instead of auto-negotiated speeds. Thanks for the explanation Ajit. > OK. It looks like platform independent then. At least cnxk driver, End > user cannot simplify change the line config parameters > while traffic is active also, it looks like other drivers need to have > SerDes training with remote partner while reconfiguring it. >=20 > At least on cnxk platform, 25Gx4 on 100G will show as 4 ethdev devices. That's a strange behaviour. Why showing 4 ports which are not independent? > Having said that, If other NICs support this feature without > disturbing current port states, I don't have an objection to this API.