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 B9FF2A0548;
Mon, 1 Nov 2021 01:23:52 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 44A5140E28;
Mon, 1 Nov 2021 01:23:52 +0100 (CET)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187])
by mails.dpdk.org (Postfix) with ESMTP id 6C1A640DF6
for <dev@dpdk.org>; Mon, 1 Nov 2021 01:23:50 +0100 (CET)
Received: from dggeme756-chm.china.huawei.com (unknown [172.30.72.57])
by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4HjDHG0lSrzZcPM;
Mon, 1 Nov 2021 08:21:46 +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.15; Mon, 1 Nov 2021 08:23:47 +0800
To: =?UTF-8?Q?Morten_Br=c3=b8rup?= <mb@smartsharesystems.com>, Andrew
Rybchenko <andrew.rybchenko@oktetlabs.ru>, <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>
<4c7d3345-1957-c85a-bf82-4c3df19f2ca8@oktetlabs.ru>
<a08dda11-474a-5814-417c-b784934491da@huawei.com>
<98CBD80474FA8B44BF855DF32C47DC35D86C81@smartserver.smartshare.dk>
From: "Min Hu (Connor)" <humin29@huawei.com>
Message-ID: <2a7361aa-962e-3491-4286-c2968467bdf0@huawei.com>
Date: Mon, 1 Nov 2021 08:23:47 +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: <98CBD80474FA8B44BF855DF32C47DC35D86C81@smartserver.smartshare.dk>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.67.103.128]
X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) 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 <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
Sender: "dev" <dev-bounces@dpdk.org>
在 2021/10/30 17:59, Morten Brørup 写道:
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Min Hu (Connor)
>> Sent: Friday, 17 September 2021 02.44
>>
>> 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) <humin29@huawei.com>
>>>>>> ---
>>>>>> 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.
>
> If ETH_SPEED_NUM_xyz values was an enum instead of #define, the default case could be removed from this switch, and the compiler would emit a warning if a new ETH_SPEED_NUM_xyz was introduced without adding a case for it in this function.
But, according to some coding standard, default case should be added in
"switch case" syntax.
>
> -Morten
>