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 A044844042; Thu, 16 May 2024 14:48:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FBB140261; Thu, 16 May 2024 14:48:27 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 653294025C for ; Thu, 16 May 2024 14:48:24 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Vg8tq533gzvSGl; Thu, 16 May 2024 20:44:51 +0800 (CST) Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84]) by mail.maildlp.com (Postfix) with ESMTPS id 35C2F180086; Thu, 16 May 2024 20:48:22 +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; Thu, 16 May 2024 20:48:21 +0800 Message-ID: Date: Thu, 16 May 2024 20:48:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/6] support setting lanes Content-Language: en-US To: Ferruh Yigit , , CC: , , , , , , , , , , References: <20240312075238.3319480-4-huangdengdui@huawei.com> <20240322070923.244417-1-huangdengdui@huawei.com> <51c392a2-0154-4191-b6cb-7ead9888eefa@amd.com> From: huangdengdui In-Reply-To: <51c392a2-0154-4191-b6cb-7ead9888eefa@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.193] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) 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 Hi, Ferruh Sorry for replying your email very late. The answers to your questions are as follows. Please correct me if I am wrong. On 2024/4/4 21:58, Ferruh Yigit wrote: > > Hi Dengdui, Damodharam, > > As details of the implementation under discussion, I have a high level > question. > > Why/when an application need to configure the lanes explicitly? > > In above description, it mentions if one port is configured as 4x25G and > other 2x50G, port can't be up. How do you end up being in this situation? > According to the Ethernet standard document[1], speed and lanes need to be configured to the PHY together. Currently, the application just set one speed like 100G to the driver. And this doesn't matter with lane number. Currently, the lane number of one NIC for a specified speed depand on their default behavior. As a result, this situation will be happened. > Lets assume first port is configured as 100G, and FW configured it as > 4x25G, and again user configured second port as 100G, why FW can't > detect this and configure ports with correct lane configuration? When the auto-negotiation is disabled, FW of the local port never know the configuration of the peer port. After all, not all NICs support auto-negotiation feature. > > In this case, if we push the responsibility to the user, when user is > configuring the second port how she will know what is the lane > configuration for first port, and what is the proper lane configuration > for the second port? So we need to support the lane query function for above reason. > > Instead of pushing this configuration to user, why it can't be handled > internally? > > As long as user requested speed configured by device, the lane > configuration has no impact to the user, right?> Is there a case/reason user need to explicitly set, lets say PAM4 > against NRZ? > Sorry, I can not understand what you mean. [1] https://lore.kernel.org/netdev/20201010154119.3537085-1-idosch@idosch.org/T/