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 6B9CF41EAF; Thu, 16 Mar 2023 10:44:18 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 56E4A42B7E; Thu, 16 Mar 2023 10:44:18 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 1BF9540FDF for ; Thu, 16 Mar 2023 10:44:17 +0100 (CET) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Pcj1j6mDwzSkpx; Thu, 16 Mar 2023 17:40:57 +0800 (CST) Received: from [10.67.100.224] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Thu, 16 Mar 2023 17:43:48 +0800 Subject: Re: [PATCH] app/testpmd: dump private info in 'show port info' To: Dmitry Kozlyuk CC: Ferruh Yigit , , Aman Singh , Yuying Zhang , References: <20230314115035.33356-1-fengchengwen@huawei.com> <20230315023328.35980-1-fengchengwen@huawei.com> <33a601b7-8e44-6dc7-923a-27d9a74c6993@amd.com> From: fengchengwen Message-ID: <6c198db8-9b0e-3929-fc54-097db956d4d8@huawei.com> Date: Thu, 16 Mar 2023 17:43:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpeml500024.china.huawei.com (7.185.36.10) 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 On 2023/3/16 17:19, Dmitry Kozlyuk wrote: > On Thu, Mar 16, 2023 at 4:11 AM fengchengwen wrote: >> Because we have no API to know the PMD whether impl specific ops, we could only knowed by invoking. >> Except above impl, I also consider the other two: >> 1. just invoke rte_eth_dev_priv_dump without previous printf("Device private info") and later error printf. >> and I think people may curious about the extra output without a prompt just like "Device private info". >> 2. use fmemopen (the below code), this way will perfect process the PMD which not imp ops. >> FILE *f = fmemopen(buf, max-size(e.g. 128KB)); >> ret = rte_eth_dev_priv_dump(port_id, f); >> if (ret == 0) { >> printf("Device private info:\n"); >> printf("%s", buf); >> } >> But the windows platform don't support fmemopen. >> >> Hope for more feedback. > > What if rte_eth_dev_priv_dump() was a documented no-op when "f == NULL"? > This can be implemented in ethdev layer: > 1) if not implemented, return ENOTSUP > 2) if f == NULL, return 0 > 3) else call PMD > Technically, even now a null device handle can be used, but this is > cumbersome and wastes resources for running the API twice. Thanks your advise. V2 has sent which adopt Thomas's comment: printf("Device private info:\n"); ret = rte_eth_dev_priv_dump(port_id, stdout); if (ret == -ENOTSUP) printf(" none\n"); else if (ret < 0) fprintf(stderr, " Failed to dump private info with error (%d): %s\n", ret, strerror(-ret)); which seem simpler. > . >