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 D1A2543D1C; Fri, 22 Mar 2024 03:28:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C54542DF1; Fri, 22 Mar 2024 03:28:38 +0100 (CET) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id 5838442DE9 for ; Fri, 22 Mar 2024 03:28:37 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4V15pd3fWNz1GCSd; Fri, 22 Mar 2024 10:28:09 +0800 (CST) Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84]) by mail.maildlp.com (Postfix) with ESMTPS id 904B41A0188; Fri, 22 Mar 2024 10:28:34 +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; Fri, 22 Mar 2024 10:28:34 +0800 Message-ID: <6f93a427-303f-472b-862c-0a65ee7837c9@huawei.com> Date: Fri, 22 Mar 2024 10:28:34 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/3] support setting lanes To: Thomas Monjalon , Damodharam Ammepalli CC: Ferruh Yigit , , , , , , , , References: <20240312075238.3319480-1-huangdengdui@huawei.com> <21ed4b3f-348b-4cf8-91d3-8d42874d7d35@huawei.com> <28052301.gRfpFWEtPU@thomas> Content-Language: en-US From: huangdengdui In-Reply-To: <28052301.gRfpFWEtPU@thomas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.193] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) 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/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 AM Thomas Monjalon wrote: >>>>> >>>>> 12/03/2024 08:52, Dengdui Huang: >>>>>> Some speeds can be achieved with different number of lanes. For example, >>>>>> 100Gbps can be achieved using two lanes of 50Gbps or four lanes 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 split 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=< integer value> and the NIC driver decides >>>> the matching combination speed x lanes that works. In future if 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 and only new >>>> drivers would consider this lanes configuration, if applicable. >>>> >>> >>> As far as I understand, lane is related to the physical layer of the >>> NIC, there are multiple copies of transmitter, receiver, modulator HW >>> block and each set called as a 'lane' and multiple lanes work together >>> to achieve desired speed. (please correct me if this is wrong). >>> >>> Why not just configuring the speed is not enough? Why user needs to know >>> the detail and configuration of the lanes? >>> Will it work if driver/device configure the "speed x lane" internally >>> 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,，multiple lanes work together to achieve desired speed. >> For example, the following solutions can be used to implement 100G: >> 1、Combines four 25G lanes >> 2、Combines two 50G lanes >> 3、A single 100G lane >> >> It is assumed that two ports are interconnected and the two ports 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 configure the >> two ports to use the same solutions (for example, uses two 50G lanes) >> 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 and 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. [1] https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9844436