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 B8957A0C46; Mon, 27 Sep 2021 18:37:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 401FF410DC; Mon, 27 Sep 2021 18:37:45 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 14A7F40E3C for ; Mon, 27 Sep 2021 18:37:42 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10120"; a="224575328" X-IronPort-AV: E=Sophos;i="5.85,326,1624345200"; d="scan'208";a="224575328" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2021 09:37:42 -0700 X-IronPort-AV: E=Sophos;i="5.85,326,1624345200"; d="scan'208";a="561278266" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.9.214]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 27 Sep 2021 09:37:40 -0700 Date: Mon, 27 Sep 2021 17:37:36 +0100 From: Bruce Richardson To: Harman Kalra Cc: "dev@dpdk.org" , "ciara.power@intel.com" , Anatoly Burakov Message-ID: References: <20210915095336.105635-1-hkalra@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] eal: add telemetry callbacks for memory info 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 Sender: "dev" On Tue, Sep 21, 2021 at 09:05:29AM +0000, Harman Kalra wrote: > > > -----Original Message----- > > From: Bruce Richardson > > Sent: Monday, September 20, 2021 9:27 PM > > To: Harman Kalra > > Cc: dev@dpdk.org; ciara.power@intel.com; Anatoly Burakov > > > > Subject: [EXT] Re: [PATCH] eal: add telemetry callbacks for memory info > > > > External Email > > > > ---------------------------------------------------------------------- > > On Wed, Sep 15, 2021 at 03:23:36PM +0530, Harman Kalra wrote: > > > Registering new telemetry callbacks to dump named (memzones) and > > > unnamed (malloc) memory information to a file provided as an argument. > > > > > > Example: > > > Connecting to /var/run/dpdk/rte/dpdk_telemetry.v2 > > > {"version": "DPDK 21.08.0", "pid": 34075, "max_output_len": 16384} > > > Connected to application: "dpdk-testpmd" > > > --> /eal/malloc_dump,/tmp/malloc_dump > > > {"/eal/malloc_dump": {"Malloc elements file: ": "/tmp/malloc_dump"}} > > > --> > > > --> /eal/malloc_info,/tmp/info > > > {"/eal/malloc_info": {"Malloc stats file: ": "/tmp/info"}} > > > --> > > > --> > > > --> /eal/memzone_dump,/tmp/memzone_info > > > {"/eal/memzone_dump": {"Memzones count: ": 11, \ "Memzones info file: > > > ": "/tmp/memzone_info"}} > > > > > > Signed-off-by: Harman Kalra > > > --- > > > > For this info, why not just send the data out as telemetry data rather than > > writing files on the filesystem containing it? If the info is too large to dump it > > all in a single go, a shortened form could be sent via some form of list call, > > and additional calls could be used to provide more detail on specific items in > > the list. > > > > Also, this seems more a debugging operation than a telemetry one, though I > > don't have a strong objection to the info being exported as telemetry directly > > (just not via filesystem). > > > > Regards, > > /Bruce > > > Hi Bruce, > > Thanks for reviewing the patch. > I have implemented these telemetry commands as a wrapper which uses existing malloc/memzone debug APIs to > collect the debug information, these debug APIs are implemented in the way that they accept a file pointer/stdout. > to get the information. > > As a solution either I should make changes to these debug APIs to accept a buffer also? Or other way could be get > the info dumped into a file, and inside telemetry command parse and convert the info into json format and send it. > But its lot of debug information so will require multiple iterations as you suggested. But on client (peer) side one > will have to again convert json to retrieve the info. > > Just for my understanding, what drawback do you see in dumping the information to a file? Because on peer side > It is very convenient to read the information from dumped file and use it. > Hi The drawback is largely a philosophical one in that what you add here are not read-operations for telemetry, but rather commands which cause the application to make changes on the running system - i.e. write out files. It's certainly something we could look to do, but I think we should only do so with some careful thought, rather than just adding it ad-hoc. Regards, /Bruce