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 C041C43D1E; Fri, 22 Mar 2024 06:51:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8957342DF1; Fri, 22 Mar 2024 06:51:42 +0100 (CET) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by mails.dpdk.org (Postfix) with ESMTP id C1D1842DE9 for ; Fri, 22 Mar 2024 06:51:41 +0100 (CET) Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-430c41f3f89so16261481cf.0 for ; Thu, 21 Mar 2024 22:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711086701; x=1711691501; 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=ZMH9QDB1UjeBDFysEamZZ6mKxr9PvDChMmRV/cEtZkE=; b=jqpL9bbcrznSO4OPVaU14W0FaSslXNJyvAABtGl4pYDl5e2EicNDsPq+f+sDDJN2AJ IX2vvmj4O5aTwZaj2mbQ4R5himnWPiUgxeB+DMvjHffC/LjsIGEZWzts5fny9U0qvnyU zZVd4Zr3Gi4czBupxBzZfcA136E4CvCJoLqgU2w3+9+Oq/7IaxjGlvKzyJw9At4AZweM PCzxfgJRZE0nMyKVgB492zJSnkeppzHgbyjuVbivxExHrwwQBjaAZiMtd9pPYh0hZBke uIwetI5jQUhQNMmX6K5cbO+UFxnc2AU0Sz82ClySgdqO3Y1VwOlBoZJW8EjiTgzJfycm Yu+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711086701; x=1711691501; 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=ZMH9QDB1UjeBDFysEamZZ6mKxr9PvDChMmRV/cEtZkE=; b=Y7cmgVgCAtQFtKEze4c68rUkZ5qABZaGvAWHDED3XE2oY/tdx9SiEknhrt0NVhA5VT HeewA1LosvLvHMGsrb72njyMJKXcAyBGNkBZoCV2OoH8hBo4lAVSF3YA18J2Avt2YtxD 64Qnmcx56xLauzxZBbqs05OQMPJPKeKrpPLFtgLHAziW6K0HB/ylMi0KCWL+lJu+MIXn diCzbaJd3UM/HJZSi+5bido2mNz71e5+g2y2aPXfyAt2WccXN3qba9hBCDaIy65YfTN0 k1VYaHiqa1ajtHt0QyfZVN4GGodRl4b5kE1naJYtF5OzORbQg1N19T1WHwqEcibY5l0z cTEw== X-Forwarded-Encrypted: i=1; AJvYcCUiQfUH05eruxroZTbBnE8Ouh53y+TrESRxrwkTH5A7C562NIfjzIXJ+QYYtFWUeeMGRHwiqsp5qbSZosE= X-Gm-Message-State: AOJu0YzUsppymiwQ6WgpHd6DhpxR/3wQ+slHDYepu5g9xzz6fvPvVML+ zNelHXN7lD8N6puL9wO4cPt0xLAwh7U7OIPhnmQ5Z/87oa6Nrbv2m2ZV5eAi3neoBmQKXrAwoxG Nr5wg5rtYbe3mdW0DnR/94IHjJi0= X-Google-Smtp-Source: AGHT+IHL/4RXSE/Fqx4brFGeOCxIsPK0CPwEZ+mRy31ZNq4A2oWagSxhdJgzIwZELhCf/LhKmdXtk5C0KZyTW9+ZQiI= X-Received: by 2002:ac8:1017:0:b0:430:bb99:45c4 with SMTP id z23-20020ac81017000000b00430bb9945c4mr1378641qti.14.1711086700984; Thu, 21 Mar 2024 22:51:40 -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: From: Jerin Jacob Date: Fri, 22 Mar 2024 11:21:14 +0530 Message-ID: Subject: Re: [PATCH 0/3] support setting lanes To: Ajit Khaparde Cc: huangdengdui , 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 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. Fo= r example, > > > >>>>>> 100Gbps can be achieved using two lanes of 50Gbps or four lane= s 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=3D< 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, modulato= r HW > > > >>> block and each set called as a 'lane' and multiple lanes work tog= ether > > > >>> 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" intern= ally > > > >>> for the requested speed? > > > >>> > > > >>> Is there a benefit to force specific lane count for a specific sp= eed > > > >>> (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= desired 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 = support > > > >> the foregoing three solutions. But, we just configured the speed t= o 100G and > > > >> one port uses four 25G lanes by default and the other port uses tw= o 50G lanes > > > >> by default, the port cannot be up. In this case, we need to config= ure the > > > >> two ports to use the same solutions (for example, uses two 50G lan= es) > > > >> 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 d= ifferent standards at the physical layer.[1] > > > So it's not possible to communicate. Configuring lanes can help the d= river 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 appropriate= ly > with the remote partner - which is just like using forced Ethernet Speed > instead of auto-negotiated speeds. 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. At least on cnxk platform, 25Gx4 on 100G will show as 4 ethdev devices. Having said that, If other NICs support this feature without disturbing current port states, I don't have an objection to this API.