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 641D8A0351;
	Tue, 22 Feb 2022 01:40:44 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id CA2D240DF4;
	Tue, 22 Feb 2022 01:40:43 +0100 (CET)
Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255])
 by mails.dpdk.org (Postfix) with ESMTP id E51274068C
 for <dev@dpdk.org>; Tue, 22 Feb 2022 01:40:42 +0100 (CET)
Received: from dggeme756-chm.china.huawei.com (unknown [172.30.72.57])
 by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4K2gFl2hn5z1FDQB;
 Tue, 22 Feb 2022 08:36:11 +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.21; Tue, 22 Feb 2022 08:40:40 +0800
Subject: Re: [PATCH] app/procinfo: add device private info dump
To: Stephen Hemminger <stephen@networkplumber.org>
CC: Thomas Monjalon <thomas@monjalon.net>, <dev@dpdk.org>,
 <ferruh.yigit@intel.com>, <maryam.tahhan@intel.com>,
 <reshma.pattan@intel.com>
References: <20220219015916.46347-1-humin29@huawei.com>
 <20220219170443.074e608f@hermes.local> <4253595.QZNE9M9tJY@thomas>
 <2b87b25c-80ed-9f2b-7a18-01aceca10b24@huawei.com>
 <20220221090457.3d6e6152@hermes.local>
From: "Min Hu (Connor)" <humin29@huawei.com>
Message-ID: <c424e007-c78a-b02c-2fee-86ba731a8a07@huawei.com>
Date: Tue, 22 Feb 2022 08:40: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: <20220221090457.3d6e6152@hermes.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.67.103.128]
X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To
 dggeme756-chm.china.huawei.com (10.3.19.102)
X-CFilter-Loop: Reflected
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


HI,

在 2022/2/22 1:04, Stephen Hemminger 写道:
> On Mon, 21 Feb 2022 10:26:38 +0800
> "Min Hu (Connor)" <humin29@huawei.com> wrote:
> 
>> Hi,
>>
>> 在 2022/2/20 16:56, Thomas Monjalon 写道:
>>> 20/02/2022 02:04, Stephen Hemminger:
>>>> On Sat, 19 Feb 2022 09:59:16 +0800
>>>> "Min Hu (Connor)" <humin29@huawei.com> wrote:
>>>>   
>>>>> +static void
>>>>> +show_port_private_info(void)
>>>>> +{
>>>>> +	int i;
>>>>> +
>>>>> +	snprintf(bdr_str, MAX_STRING_LEN, " show - Port PMD Private ");
>>>>> +	STATS_BDR_STR(10, bdr_str);
>>>>> +
>>>>> +	for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
>>>>> +		/* Skip if port is not in mask */
>>>>> +		if ((enabled_port_mask & (1ul << i)) == 0)
>>>>> +			continue;
>>>>> +
>>>>> +		/* Skip if port is unused */
>>>>> +		if (!rte_eth_dev_is_valid_port(i))
>>>>> +			continue;
>>>>
>>>> Maybe use RTE_ETH_FOREACH_DEV(i) here?
>>>>
>>>> Procinfo is somewhat inconsistent, some code uses, and some does not.
>>>> The difference is that FOREACH skips ports that are "owned" i.e
>>>> associated with another port.
>>>
>>> Yes RTE_ETH_FOREACH_DEV is for general usage,
>>> you get only the ports you are supposed to manage.
>>>    
>>>> There probably should be a clear policy in the comments about
>>>> how this command should handle ports.  My preference would be
>>>> that it shows all valid ports, all the time since this is a diagnostic
>>>> command used to debug misconfiguration.
>>>>
>>>> There is RTE_ETH_FOREACH_VALID_DEV but it is marked internal?
>>>
>>> Yes, you get it right, RTE_ETH_FOREACH_VALID_DEV gets all ports
>>> and that should be used only internally or for debugging.
>>> If we expose it for debugging purpose, there is a risk of confusion.
>>> The goal was to "force" applications to adopt good behaviour,
>>> using RTE_ETH_FOREACH_DEV.
>> Agree with using RTE_ETH_FOREACH_DEV, v2 has been sent out.
>>
>>> It means RTE_MAX_ETHPORTS must be used for debugging.
>>> Is it a good decision?
>>>
>>>
>>> .
>>>    
> 
> Maybe procinfo should have a flag (--all) to show all devices.
How about keep the patch as v1 shows, like that:
+	for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
+		/* Skip if port is not in mask */
+		if ((enabled_port_mask & (1ul << i)) == 0)
+			continue;
+
+		/* Skip if port is unused */
+		if (!rte_eth_dev_is_valid_port(i))
+			continue;

This can show all devices.
> .
>