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 A45E4A0093; Thu, 16 Jun 2022 10:19:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C00F4281E; Thu, 16 Jun 2022 10:19:27 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 13E8A4114F for ; Thu, 16 Jun 2022 10:19:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655367566; x=1686903566; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=X5momG+X60tqqCB3Qf8wM2sHtoNu6nZRlLHdP/sCBNY=; b=UM4EqI1Lp8Y6rI+hFwo2QtKxkZxxbBBFk6B0xMPT+vhzQLZWvdAPiG0L A2c9c2E7ZsfRtSaAO5P01xsz2SeaDV8/5OlU4V3RrH6nyFVqQjzynU/VJ o61VeUkK3ybzoXGcw9gYn8h/ClbNwVnvvxO+Vi8a2u33nHhvfJv5JtO3F Qk0Equt+RoNUUHvrXL44FU/HBJHufb6KvFOLdtqetrBzgi3Uu2L2PaNgE I4sSaoHX2aiPQOkTd0B6y1wBJW2XZPwYKh1Rd3E2Em5c9AmxG6WRVQaVS y7Rapc5h/2jJPpBBOvF3+pqSg8k/0jiCKVTw01cRU1AD8TDZpnqbv1iZS Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10379"; a="343155027" X-IronPort-AV: E=Sophos;i="5.91,304,1647327600"; d="scan'208";a="343155027" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2022 01:19:24 -0700 X-IronPort-AV: E=Sophos;i="5.91,304,1647327600"; d="scan'208";a="727796807" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.23.119]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Jun 2022 01:19:22 -0700 Date: Thu, 16 Jun 2022 09:19:19 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Chengwen Feng , thomas@monjalon.net, ferruh.yigit@xilinx.com, kevin.laatz@intel.com, andrew.rybchenko@oktetlabs.ru, jerinj@marvell.com, sachin.saxena@oss.nxp.com, hemant.agrawal@nxp.com, dev@dpdk.org Subject: Re: [PATCH 0/5] support telemetry dump dev Message-ID: References: <20220615073915.14041-1-fengchengwen@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35D8712A@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8712A@smartserver.smartshare.dk> 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 Wed, Jun 15, 2022 at 10:15:27PM +0200, Morten Brørup wrote: > > From: Chengwen Feng [mailto:fengchengwen@huawei.com] > > Sent: Wednesday, 15 June 2022 09.39 > > > > This patchset contains five patch which support telemetry dump > > dmadev/eventdev/rawdev/ethdev. > > > > Chengwen Feng (5): > > usertools: use non-strict when json-loads in telemetry > > dmadev: support telemetry dump dmadev > > eventdev: support telemetry dump eventdev > > rawdev: support telemetry dump rawdev > > ethdev: support telemetry private dump > > > > lib/dmadev/rte_dmadev.c | 39 +++++++++++++++++++++++++++++++++ > > lib/ethdev/rte_ethdev.c | 42 ++++++++++++++++++++++++++++++++++++ > > lib/eventdev/rte_eventdev.c | 43 +++++++++++++++++++++++++++++++++++++ > > lib/rawdev/rte_rawdev.c | 42 ++++++++++++++++++++++++++++++++++++ > > usertools/dpdk-telemetry.py | 2 +- > > 5 files changed, 167 insertions(+), 1 deletion(-) > > > > -- > > 2.33.0 > > > > While hoping for someone to fix the Telemetry library bug regarding the missing JSON encoding of strings (https://bugs.dpdk.org/show_bug.cgi?id=1037), thus making the patch regarding usertools/dpdk-telemetry.py superfluous, > > Series-Acked-by: Morten Brørup > I disagree with taking this series without fixing the underlying issue. I don't think we should be sending invalid json data so doing proper escaping of \n\t etc. characters on encode is the best solution. There is also some merit in adding in support for tagging strings that don't contain invalid characters, if perf is affected in some cases. That said, in the testing I have done in the past: * for jobs like getting the nic stats or nic xstats, the vast majority of the cycles spent in the telemetry function is doing PCI reads for the stats * for simpler jobs e.g. getting list of ethdevs, the vast majority of the time is actually being spent in the kernel socket handling Based on what I've seen (and unfortunately I didn't note down the exact figures for above), its likely that even if performance of the interface is a concern we can probably add in some basic string encoding without really affecting things much. /Bruce