From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id CA2B843DC0;
Tue, 2 Apr 2024 10:37:44 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 543D54028C;
Tue, 2 Apr 2024 10:37:44 +0200 (CEST)
Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35])
by mails.dpdk.org (Postfix) with ESMTP id 90E684026F
for <dev@dpdk.org>; Tue, 2 Apr 2024 10:37:42 +0200 (CEST)
Received: from mail.maildlp.com (unknown [172.19.88.163])
by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4V81Ql17l8z1R9hq;
Tue, 2 Apr 2024 16:34:55 +0800 (CST)
Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84])
by mail.maildlp.com (Postfix) with ESMTPS id 4297218002D;
Tue, 2 Apr 2024 16:37:40 +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; Tue, 2 Apr 2024 16:37:39 +0800
Message-ID: <5f97ce5c-156e-4250-930f-01c5befdb681@huawei.com>
Date: Tue, 2 Apr 2024 16:37:39 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes
Content-Language: en-US
To: Thomas Monjalon <thomas@monjalon.net>, Damodharam Ammepalli
<damodharam.ammepalli@broadcom.com>
CC: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>, Ajit Khaparde
<ajit.khaparde@broadcom.com>, "lihuisong (C)" <lihuisong@huawei.com>,
<roretzla@linux.microsoft.com>, <dev@dpdk.org>, <ferruh.yigit@amd.com>,
<aman.deep.singh@intel.com>, <yuying.zhang@intel.com>,
<andrew.rybchenko@oktetlabs.ru>, <stephen@networkplumber.org>,
<jerinjacobk@gmail.com>, <liuyonglong@huawei.com>, <fengchengwen@huawei.com>,
<haijie1@huawei.com>
References: <20240312075238.3319480-4-huangdengdui@huawei.com>
<CAKSYD4wgF5rAWpVo=aFk0EV4p_+n+PvQNF+Byj1ekGP--5rZtQ@mail.gmail.com>
<5d2ab42c-4b56-4a40-8e0c-3ac9a5e34ec6@huawei.com> <4326199.QLehXeTyEo@thomas>
From: huangdengdui <huangdengdui@huawei.com>
In-Reply-To: <4326199.QLehXeTyEo@thomas>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On 2024/4/2 4:07, Thomas Monjalon wrote:
> 30/03/2024 12:38, huangdengdui:
>> But, there are different solutions for the device to report the setting
>> lane capability, as following:
>> 1. Like the current patch, reporting device capabilities in speed and
>> lane coupling mode. However, if we use this solution, we will have
>> to couple the the lanes setting with speed setting.
>>
>> 2. Like the Damodharam's RFC patch [1], the device reports the maximum
>> number of supported lanes. Users can config a lane randomly,
>> which is completely separated from the speed.
>>
>> 3. Similar to the FEC capability reported by a device, the device reports the
>> relationship table of the number of lanes supported by the speed,
>> for example:
>> speed lanes_capa
>> 50G 1,2
>> 100G 1,2,4
>> 200G 2,4
>>
>> Options 1 and 2 have been discussed a lot above.
>>
>> For solution 1, the speed and lanes are over-coupled, and the implementation is too
>> complex. But I think it's easier to understand and easier for the device to report
>> capabilities. In addition, the ethtool reporting capability also uses this mode.
>>
>> For solution 2, as huisong said that user don't know what lanes should or can be set
>> for a specified speed on one NIC.
>>
>> I think that when the device reports the capability, the lanes should be associated
>> with the speed. In this way, users can know which lanes are supported by the current
>> speed and verify the configuration validity.
>>
>> So I think solution 3 is better. What do you think?
>
> I don't understand your proposals.
> Please could you show the function signature for each option?
>
>
I agree with separating the lanes setting from the speed setting.
I have a different proposal for device lanes capability reporting.
Three interfaces are added to the lib/ethdev like FEC interfaces.
1. rte_eth_lanes_get(uint16_t port_id, uint32_t *capa) /* get current lanes */
2. rte_eth_lanes_set(uint16_t port_id, uint32_t capa)
3. rte_eth_lanes_get_capa(uint16_t port_id, struct rte_eth_lanes_capa *speed_lanes_capa)
/* A structure used to get capabilities per link speed */
struct rte_eth_lanes_capa {
uint32_t speed; /**< Link speed (see RTE_ETH_SPEED_NUM_*) */
uint32_t capa; /**< lanes capabilities bitmask */
};
For example, an ethdev report the following lanes capability array:
struct rte_eth_lanes_capa[] device_capa = {
{ RTE_ETH_SPEED_NUM_50G, 0x0003 }, //supports lanes 1 and 2 for 50G
{ RTE_ETH_SPEED_NUM_100G, 0x000B } //supports lanes 1, 2 and 4 for 100G
};
The application can know which lanes are supported at a specified speed.
I think it's better to implement the setting lanes feature in this way.
Welcom to jump into discuss.