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 56404A0C41; Thu, 16 Sep 2021 10:21:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 186FF4003F; Thu, 16 Sep 2021 10:21:23 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 547D64003E for ; Thu, 16 Sep 2021 10:21:21 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id DEC737F53D; Thu, 16 Sep 2021 11:21:20 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru DEC737F53D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1631780480; bh=LFZsLI9et58OITCJANxAJZtPbk+I1yUbGuER5eP+Cts=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ik6S/6mth/c0vYl1oStzXsFwE5ras6/6wm8TpqXOKbgLTKT6pPge1Kp0N7QyD5pGI +KPs8/cHHL/2x8VeNkCmWEI+c2dUgksKyHdnqmX1vrDXDoASlF2dU5ZBNPYE5II4ju 30OLA++P01eAHw7pwW/QfgEVGHrwJ9KMpPsCaRp8= To: "Min Hu (Connor)" , dev@dpdk.org Cc: ferruh.yigit@intel.com, thomas@monjalon.net 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> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <4c7d3345-1957-c85a-bf82-4c3df19f2ca8@oktetlabs.ru> Date: Thu, 16 Sep 2021 11:21:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <7de60ca1-b652-e102-01c6-ec069ac00baa@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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" 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.