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 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 ; 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 , Damodharam Ammepalli CC: Damodharam Ammepalli , Ajit Khaparde , "lihuisong (C)" , , , , , , , , , , , References: <20240312075238.3319480-4-huangdengdui@huawei.com> <5d2ab42c-4b56-4a40-8e0c-3ac9a5e34ec6@huawei.com> <4326199.QLehXeTyEo@thomas> From: huangdengdui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.