From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26D86C47DD9 for ; Fri, 22 Mar 2024 04:39:04 +0000 (UTC) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EE73542DE9; Fri, 22 Mar 2024 05:39:02 +0100 (CET) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by mails.dpdk.org (Postfix) with ESMTP id E96D042DC4 for ; Fri, 22 Mar 2024 05:39:01 +0100 (CET) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-430a7497700so13064181cf.1 for ; Thu, 21 Mar 2024 21:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711082341; x=1711687141; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+i3TDa/1bhKyUO2gD8UMANE9ySVbmDKKtoaLAkb07K4=; b=WJqwWdua2WjbfzGjGTvqKplgyxKHP0hAMP0/CvlIqAJN/0kkdwHuvcMZF5GfqnkkXE CG6zqVMnqWYBNyx12Hg/1XQS3lC2IFxjywWAHdsxOHBki4im2ysFm+p5H+t4zQO4CXWJ IMm0vGEy64MhYy2vMvIBZtOPeZl2xJz421zZmfYXQwke91zhzFG7gTtcvzYVMwU3OvBg SYI7OOoYIaXljjONgLqFqEGYOH1ApVt7EVXMCPU7e5aVZZB+MTE6tl+oNkh33cGW4Bgs 4IpfXqZUu7vn3pb5IpJd/0FRjM5pz4WmiLycCntgVISF9zdW8D3JnIvsA7eRg8JS35Mv NrNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711082341; x=1711687141; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+i3TDa/1bhKyUO2gD8UMANE9ySVbmDKKtoaLAkb07K4=; b=Gwt1vYFF5BX3nNPlUmTm2kfN0gPG9WrwdA47bs6zgJRCf/IlIFsXs3ZWZGNKba/v9h eTS2oGY6gSngx7HlufPx4AkmsMlTi4FGYVvcWT6gJxsZ9Co4BhAIFZlC9qNruZgvBvj0 FbtEBLiGTuDWxdNZ2peUnEI3jg9sHwqD7fIng0kt0xdJ3HQQdpUkiZ1+xgyXnEj3GwEF jjw6B7mvSawBNcO/4j/JuKephhqVPThtA4Lpy0uO1YLIyxkRnK2H1mhHEf0iObMkSuUI 9Ub2xC7iC6xnYIyclKNsKvcjKd1MFVnWkx8PqKSnXDZ6bfRZ9vXmHo9E9zvycSvxFXna Mpyw== X-Forwarded-Encrypted: i=1; AJvYcCXFQ1lw7rTwpaHP7SM0J7JmWzPzKMoV2vjfuVH5TBcoJNnyuXujAioojRiIU56puUzTCgAVMLEQyW//84g= X-Gm-Message-State: AOJu0YxQySl9pU8fzuxZgXO/7pTGLuxmMFitI+H5aw6mx6yVPe5RZKIV q7qT7zA0z5cR+Gx7LIReeBT8+UUGKJYdBs+sIhBriqJhnbKgGUotUN61jxOTSGjyh+WJt1v8BUO u7JKd5+8lQoCsUkhBa8lH8i4/dqE= X-Google-Smtp-Source: AGHT+IFLM7/k58u+2fRbi/1Cl40jToxdpSVy7PIAFP7OA81MVKC3mB4svAIQLBw1eSuRW77dtDi3jl7onY6XIu2S5jI= X-Received: by 2002:a05:622a:528a:b0:431:3107:2d98 with SMTP id dr10-20020a05622a528a00b0043131072d98mr505534qtb.6.1711082340997; Thu, 21 Mar 2024 21:39:00 -0700 (PDT) MIME-Version: 1.0 References: <20240312075238.3319480-1-huangdengdui@huawei.com> <21ed4b3f-348b-4cf8-91d3-8d42874d7d35@huawei.com> <28052301.gRfpFWEtPU@thomas> <6f93a427-303f-472b-862c-0a65ee7837c9@huawei.com> In-Reply-To: <6f93a427-303f-472b-862c-0a65ee7837c9@huawei.com> From: Jerin Jacob Date: Fri, 22 Mar 2024 10:08:34 +0530 Message-ID: Subject: Re: [PATCH 0/3] support setting lanes To: huangdengdui Cc: Thomas Monjalon , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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. For ex= ample, > >>>>>> 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 l= anes? > >>>>> 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 driver dec= ides > >>>> the matching combination speed x lanes that works. In future if a ne= w 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 togethe= r > >>> to achieve desired speed. (please correct me if this is wrong). > >>> > >>> Why not just configuring the speed is not enough? Why user needs to k= now > >>> 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,=EF=BC=8Cmultiple lanes work together to achieve des= ired speed. > >> For example, the following solutions can be used to implement 100G: > >> 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 ports supp= ort > >> the foregoing three solutions. But, we just configured the speed to 10= 0G and > >> one port uses four 25G lanes by default and the other port uses two 50= G 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 diffe= rent standards at the physical layer.[1] > So it's not possible to communicate. Configuring lanes can help the drive= r 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? 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. > https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D9844436