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 7BF2341EB1; Thu, 16 Mar 2023 16:16:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6C3BC42D59; Thu, 16 Mar 2023 16:16:28 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id CADB740DDC; Thu, 16 Mar 2023 16:16:25 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 70FF75C009A; Thu, 16 Mar 2023 11:16:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 16 Mar 2023 11:16:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type: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=fm2; t= 1678979784; x=1679066184; bh=04+35Crku0wk0gIY6BMRyXlrGdYl7B3LiL9 s6MdEXTo=; b=uJdEDEJAHh9NZXHf8oxs+OCXI8KJJI1wCKiUHTI7N/LIydCBoAA wm05OQHmKkmXC+nLxA2cvRUmFQ9at4LzqvfcVMumsyb5fhRRCBS0M6DQ1yqHLUgN T68ng4W5ZZE3KL09+xsus00HdoSUyxW7/I4rk8A8Wo2jNaVvkofQ/O1yu9AGBsz+ oiHmVFJIUm6h7TCB5807bVSO/AOtvKTDSAEj4Sti6+SeZ80IArUxfloAjr59YNUu vUpcTLtMJPuqY+beBdZdR9S9KPnN26EmtzjNjqpzvVG4x8mHGnNVu/iy5u9ZpxoP c2ruug6SsHnNRO5xaLK6q3FhXqBPLSSiHiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :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; t= 1678979784; x=1679066184; bh=04+35Crku0wk0gIY6BMRyXlrGdYl7B3LiL9 s6MdEXTo=; b=FZhsHE5dcR2tZ9wa4H3QsuLO5p9R1yX0zEmzK10YuswrbeTRwmM 5rWySJMricyjIPTpMAAcf3s33BZ1tC5M8a86P4VON+mGyWt1mW0drT/hH15nUYE2 n8PX+ORz5gpTgqi99jBclKtkRlSg6dLpNWd3X4nJDZ70tExS5S++NzbMa8QjWHo/ IL7z+6nCEKSwBtz9pDb/2mUuAgDUrvLyLMUVE/rNIHnp5Z8ca4aAPvBeQIiUdn+S 5xf0RECfYh2ezP6YDpJ9gtK1/8Qe5814GkvOMV/BolHotTN13w9Lh7CiDuXKAnOF pySOIf9/XxmLdv8qfUgK/Pp5OhITmrq6Xfw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeftddgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 16 Mar 2023 11:16:22 -0400 (EDT) From: Thomas Monjalon To: Dmitry Kozlyuk , fengchengwen , Ferruh Yigit Cc: Aman Singh , Yuying Zhang , dev@dpdk.org, "techboard@dpdk.org" , Andrew Rybchenko , David Marchand , Akhil Goyal Subject: Re: [PATCH] app/testpmd: dump private info in 'show port info' Date: Thu, 16 Mar 2023 16:16:20 +0100 Message-ID: <1844579.tdWV9SEqCh@thomas> In-Reply-To: <130d8ac9-967f-16b0-103f-84d4bcaa81f0@amd.com> References: <20230314115035.33356-1-fengchengwen@huawei.com> <130d8ac9-967f-16b0-103f-84d4bcaa81f0@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 16/03/2023 11:46, Ferruh Yigit: > On 3/16/2023I 9:19 AM, Dmitry Kozlyuk wrote: > > On Thu, Mar 16, 2023 at 4:11=E2=80=AFAM fengchengwen wrote: > >> Because we have no API to know the PMD whether impl specific ops, we c= ould 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 p= rivate info") and later error printf. > >> and I think people may curious about the extra output without a pro= mpt just like "Device private info". > >> 2. use fmemopen (the below code), this way will perfect process the PM= D which not imp ops. > >> FILE *f =3D fmemopen(buf, max-size(e.g. 128KB)); > >> ret =3D rte_eth_dev_priv_dump(port_id, f); > >> if (ret =3D=3D 0) { > >> printf("Device private info:\n"); > >> printf("%s", buf); > >> } > >> But the windows platform don't support fmemopen. > >> > >> Hope for more feedback. > >=20 > > What if rte_eth_dev_priv_dump() was a documented no-op when "f =3D=3D N= ULL"? > > This can be implemented in ethdev layer: > > 1) if not implemented, return ENOTSUP > > 2) if f =3D=3D 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. >=20 >=20 > Not sure about to overload "f =3D=3D NULL" condition to detect the feature > support. >=20 > It may be good to have a generic way to detect the support. >=20 > One way is to add new set of APIs just to test the dev_ops, and return > boolean like: > 'bool rte_eth_dev_is_priv_dump(uint16_t port_id);' >=20 >=20 > Another option can be introducing an enum, each enum item can represent > a dev_ops and a single API can be used to detect the support. This > requires more maintenance for long term, as app needs to know more, > not sure if I like this. >=20 >=20 > If there is no objection to add new APIs, I can own the task, to have > APIs like: > 'bool rte_eth_dev_is_xxx(uint16_t port_id);' That's a debug function, so I don't think we need to know in advance whether it will print something or not. Returning ENOTSUP should be enough in my opinion.