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 7D7FCA00C2; Sun, 20 Feb 2022 09:56:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0DC984068C; Sun, 20 Feb 2022 09:56:31 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 2FC7540395 for ; Sun, 20 Feb 2022 09:56:30 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 4430C3200A6A; Sun, 20 Feb 2022 03:56:24 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 20 Feb 2022 03:56:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=LOLDxx8AwyEoH8 WsxLP0Ni55wzLVl0U0BRrWY9Kx1+I=; b=eQABEuFHy62wTHI8Sh2WWWxAtB2qwL kIIrt+s0+L68xg/egdcGmaNZZTf0QHvSS71ea91HAbyJoMdNS7I13XmcMYBsVWvY su+ZYzVvk0ekZJjMdu14R7ICQ+2vhW3oZd9oaJgfhKFxvnBRLF/LtBxSSrs/xSnV sk4l1fvDHFhFk/MlN5XWakGV+TJliXeHGt3SBvRLJ0Fx29A/HOXtgB8f2+uA63je UaKUcgJhMp6kSycdl9t1eRh78KGuPScyPP/PTI9eP0f1iCm40SeAueQxFhnphmJz /IHxzilmSrziFPZqmvf+psCM0qVRp5yFx7QoSLwFMH9cJo626uzQNIGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=LOLDxx8AwyEoH8WsxLP0Ni55wzLVl0U0BRrWY9Kx1 +I=; b=gjSwKXj6mKDN4cJSUiOBNeY2NjpIztHO2IdVdYkCGZG5RY9m6Xb+kh+qo uEe5MQjMgCAF5uBuJvOmQOQJfMZoyvX3eAzTs2yMBWxBTmYYRFE5GmGTvahYp8e1 2hA12wWg5DGLRBC3et4FakUxuwztRfLHf9jR2b9aGqg9zlHMykHDXUOwA8q0yCS9 d2r6p2Cs4bkZ148IGvR9lfPJ0OXbSz8xn2J6wUfTpu9OicpZl4P/wmXs2oXtFofN HR0NzLRBwP+kK4piN/bp7YK3yoR0A10jwj8ZD6MuxFAIYK6rErBmxM/7pEEcMHoO xadMkCUHUniApxD3HIQ7uA/b8TBTw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkeefgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 20 Feb 2022 03:56:22 -0500 (EST) From: Thomas Monjalon To: "Min Hu (Connor)" , Stephen Hemminger Cc: dev@dpdk.org, ferruh.yigit@intel.com, maryam.tahhan@intel.com, reshma.pattan@intel.com Subject: Re: [PATCH] app/procinfo: add device private info dump Date: Sun, 20 Feb 2022 09:56:20 +0100 Message-ID: <4253595.QZNE9M9tJY@thomas> In-Reply-To: <20220219170443.074e608f@hermes.local> References: <20220219015916.46347-1-humin29@huawei.com> <20220219170443.074e608f@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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. It means RTE_MAX_ETHPORTS must be used for debugging. Is it a good decision?