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 C919DA034E; Mon, 21 Feb 2022 03:26:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5EB7B4068C; Mon, 21 Feb 2022 03:26:43 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id C8E9040395 for ; Mon, 21 Feb 2022 03:26:41 +0100 (CET) Received: from dggeme756-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4K25jj5rZvz9snC; Mon, 21 Feb 2022 10:24:57 +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; Mon, 21 Feb 2022 10:26:39 +0800 Subject: Re: [PATCH] app/procinfo: add device private info dump To: Thomas Monjalon , Stephen Hemminger CC: , , , References: <20220219015916.46347-1-humin29@huawei.com> <20220219170443.074e608f@hermes.local> <4253595.QZNE9M9tJY@thomas> From: "Min Hu (Connor)" Message-ID: <2b87b25c-80ed-9f2b-7a18-01aceca10b24@huawei.com> Date: Mon, 21 Feb 2022 10:26:38 +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: <4253595.QZNE9M9tJY@thomas> Content-Type: text/plain; charset="gbk"; 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 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 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)" 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? > > > . >