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 978C3A0C43; Fri, 17 Sep 2021 02:43:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 133F04069E; Fri, 17 Sep 2021 02:43:43 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 1B83A40689 for ; Fri, 17 Sep 2021 02:43:42 +0200 (CEST) Received: from dggeme756-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4H9ZpX3WHDzbjLn; Fri, 17 Sep 2021 08:39:32 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by dggeme756-chm.china.huawei.com (10.3.19.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Fri, 17 Sep 2021 08:43:39 +0800 To: Andrew Rybchenko , CC: , References: <29b75903-d212-c6e6-eedf-e3bc92ab816a@huawei.com> <20210916025636.48024-1-humin29@huawei.com> <080fa0c3-c518-0e7f-f6d5-146dc9430d27@oktetlabs.ru> <7de60ca1-b652-e102-01c6-ec069ac00baa@huawei.com> <4c7d3345-1957-c85a-bf82-4c3df19f2ca8@oktetlabs.ru> From: "Min Hu (Connor)" Message-ID: Date: Fri, 17 Sep 2021 08:43:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <4c7d3345-1957-c85a-bf82-4c3df19f2ca8@oktetlabs.ru> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.128] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggeme756-chm.china.huawei.com (10.3.19.102) X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [RFC] ethdev: improve link speed to string 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 Sender: "dev" Agree with you. Thanks Andrew 在 2021/9/16 16:21, Andrew Rybchenko 写道: > On 9/16/21 11:16 AM, Min Hu (Connor) wrote: >> Hi, Andrew, >> >> 在 2021/9/16 14:22, Andrew Rybchenko 写道: >>> On 9/16/21 5:56 AM, Min Hu (Connor) wrote: >>>> Currently, link speed to string only supports specific speeds, like 10M, >>>> 100M, 1G etc. >>>> >>>> This patch expands support for any link speed which is over 1M and one >>>> decimal place will kept for display at most. >>>> >>>> Signed-off-by: Min Hu (Connor) >>>> --- >>>>   lib/ethdev/rte_ethdev.c | 34 +++++++++++++++++----------------- >>>>   1 file changed, 17 insertions(+), 17 deletions(-) >>>> >>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c >>>> index daf5ca9242..1d3b960305 100644 >>>> --- a/lib/ethdev/rte_ethdev.c >>>> +++ b/lib/ethdev/rte_ethdev.c >>>> @@ -2750,24 +2750,24 @@ rte_eth_link_get_nowait(uint16_t port_id, >>>> struct rte_eth_link *eth_link) >>>>   const char * >>>>   rte_eth_link_speed_to_str(uint32_t link_speed) >>>>   { >>>> -    switch (link_speed) { >>>> -    case ETH_SPEED_NUM_NONE: return "None"; >>>> -    case ETH_SPEED_NUM_10M:  return "10 Mbps"; >>>> -    case ETH_SPEED_NUM_100M: return "100 Mbps"; >>>> -    case ETH_SPEED_NUM_1G:   return "1 Gbps"; >>>> -    case ETH_SPEED_NUM_2_5G: return "2.5 Gbps"; >>>> -    case ETH_SPEED_NUM_5G:   return "5 Gbps"; >>>> -    case ETH_SPEED_NUM_10G:  return "10 Gbps"; >>>> -    case ETH_SPEED_NUM_20G:  return "20 Gbps"; >>>> -    case ETH_SPEED_NUM_25G:  return "25 Gbps"; >>>> -    case ETH_SPEED_NUM_40G:  return "40 Gbps"; >>>> -    case ETH_SPEED_NUM_50G:  return "50 Gbps"; >>>> -    case ETH_SPEED_NUM_56G:  return "56 Gbps"; >>>> -    case ETH_SPEED_NUM_100G: return "100 Gbps"; >>>> -    case ETH_SPEED_NUM_200G: return "200 Gbps"; >>>> -    case ETH_SPEED_NUM_UNKNOWN: return "Unknown"; >>>> -    default: return "Invalid"; >>>> +#define SPEED_STRING_LEN 16 >>>> +    static char name[SPEED_STRING_LEN]; >>> >>> NACK >>> >>> Nothing good will happen if you try to use the function to >>> print two different link speeds in one log message. >> You are right. >> And use malloc for "name" will result in memory leakage, which is also >> not a good option. >> >> BTW, do you think if we need to modify the function >> "rte_eth_link_speed_to_str"? > > IMHO it would be more pain than gain in this case. > > . >