From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 922C3A0597; Thu, 9 Apr 2020 11:19:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E32881C1DE; Thu, 9 Apr 2020 11:19:20 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 7D9961C1C6 for ; Thu, 9 Apr 2020 11:19:19 +0200 (CEST) IronPort-SDR: oT0x6Q0NpNf6G5508yulQ3QpUacjc6173e70P+CKBanWl/nSEaHoX5ms35EATFiaJHLz/tUY38 8CMQY8IGiXFQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2020 02:19:18 -0700 IronPort-SDR: Ylj+shmPe7LhqDvZ1t8m9wabSlhIZBKbg74mfvwH+fzPaMjdod0INqoWPrZ+/KM2oAhFxn9wXY HKbr1PIn0Wpw== X-IronPort-AV: E=Sophos;i="5.72,362,1580803200"; d="scan'208";a="240567048" Received: from bricha3-mobl.ger.corp.intel.com ([10.214.222.217]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Apr 2020 02:19:14 -0700 Date: Thu, 9 Apr 2020 10:19:09 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: Ciara Power , dev@dpdk.org, kevin.laatz@intel.com, reshma.pattan@intel.com, jerinjacobk@gmail.com, david.marchand@redhat.com, keith.wiles@intel.com, mb@smartsharesystems.com Message-ID: <20200409091909.GC605@bricha3-MOBL.ger.corp.intel.com> References: <20200319171907.60891-1-ciara.power@intel.com> <20200408164956.47864-1-ciara.power@intel.com> <2104953.NgBsaNRSFp@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2104953.NgBsaNRSFp@thomas> Subject: Re: [dpdk-dev] [PATCH v2 00/16] update and simplify telemetry library. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Wed, Apr 08, 2020 at 08:03:26PM +0200, Thomas Monjalon wrote: > 08/04/2020 18:49, Ciara Power: > > This patchset extensively reworks the telemetry library adding new > > functionality and simplifying much of the existing code, while > > maintaining backward compatibility. > > > > This work is based on the previously sent RFC for a "process info" > > library: https://patchwork.dpdk.org/project/dpdk/list/?series=7741 > > However, rather than creating a new library, this patchset takes > > that work and merges it into the existing telemetry library, as > > mentioned above. > > > > The telemetry library as shipped in 19.11 is based upon the metrics > > library and outputs all statistics based on that as a source. However, > > this limits the telemetry output to only port-level statistics > > information, rather than allowing it to be used as a general scheme for > > telemetry information across all DPDK libraries. > > > > With this patchset applied, rather than the telemetry library being > > responsible for pulling ethdev stats and pushing them into the metrics > > library for retrieval later, each library e.g. ethdev, rawdev, and even > > the metrics library itself (for backwards compatiblity) now handle their > > own stats. Any library or app can register a callback function with > > telemetry, which will be called if requested by the client connected via > > the telemetry socket. The callback function in the library/app then > > formats its stats, or other data, into a JSON string, and returns it to > > telemetry to be sent to the client. > > I think this is a global need in DPDK, and it is usually called RPC, > IPC or control messaging. > We had a similar need for multi-process communication, thus rte_mp IPC. > We also need a control channel for user configuration applications. > We also need to control some features like logging or tracing. > > In my opinion, it is time to introduce a general control channel in DPDK. > The application must be in the loop of the control mechanism. > Making such channel standard will ease application adoption. > > Please read some comments here: > http://inbox.dpdk.org/dev/2580933.jp2sp48Hzj@xps/ > Hi Thomas, I agree that having a single control mechanism or messaging mechanism in DPDK would be nice to have. However, I don't believe the plans for such a scheme should impact this patchset right now as the idea of a common channel was only first mooted about a week ago, and while there has been some email discussion about it, there is as yet no requirements list that I've seen, nobody actually doing coding work on it, no rfc and most importantly no timeline for creating and merging such into DPDK. At present though, DPDK has a telemetry solution that works for the use case of ethdev stats and some power management info, but requires a more general solution to allow monitoring tools like PMDT to introspect DPDK, and also to prove statistics for other parts of DPDK such as cryptodev, eventdev, and other libraries, plus the application itself if the app so desires. Regards, /Bruce