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 E0CC6A00C2; Thu, 23 Apr 2020 12:44:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B56B61D408; Thu, 23 Apr 2020 12:44:18 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 471021D181 for ; Thu, 23 Apr 2020 12:44:17 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 556105801A3; Thu, 23 Apr 2020 06:44:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 23 Apr 2020 06:44:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= MJFNdZBajdNliXa42GYWWZ8z9ZV/XdZ9/lCzJRRe910=; b=UiVr1JuxuCtaC3Hg 9EdDzA/SZjQ8c3xsMvvZTwktpgN4OMmu/vMJ/NqcsLHuaeq72WrdwiBhgUCk3Dw3 3uHJjrKmqHqVnqL0jTQttjVlupH4hDbFkWFwfwC8NzA6Kr6Vv48rt/as2xn+gOIf znPr3YISUyAPjdPTVL7ufE2SqPasQiONHP/UVfeGC08qquaG/KQL/cQyVsbODSAx hFaVTi8Hg6+848wK0D9KcJl/y9OL0mKAZvK12+wCGIyjg0V/eV1I6JcmBMWfqZbI GFayrxjdZ/imnsG/3oh+rbzZmZEW6ZdEfmo8yS2cu1OjEh4k2+y6IY1pFW509zCh 4r5DKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=MJFNdZBajdNliXa42GYWWZ8z9ZV/XdZ9/lCzJRRe9 10=; b=N2Z5oo2+goKFONSpre9BBLn5xi42NMIRq2UsXAUg2qf/2WmbzGvLQkd88 IMALi1d392Vh5qNJJ1THxJ/r3gwpiSkqF6g5SQCso6b7l4kCkLGCpMdvdE3hFtSU BK6Q3g0AOmUZ1/pERQdYY/pz84OLq40Od+R+5/6wxdqoQ/OUQkWRm+MjWulpbmkH nHV1RoxGq3eC+qAjIzqc8Y1obHbsKUn8+Yz2LlRsz8u3UMfwDNOvtUMgVbjAw/NR u+iInIHihlZBsWFGEB46Y+mmCc4x28//2laRtkuMqtMoEPCcAD4mA+SxsGp2VdZ2 TKTMjPBDPc99K4Q88FxXtRPL9wrIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeelgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgpdiivghrohhmqhdrohhrghenucfkphepjeejrddufeeg rddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3B1213065D30; Thu, 23 Apr 2020 06:44:13 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , Luca Boccassi 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, aostruszka@marvell.com, amo@semihalf.com Date: Thu, 23 Apr 2020 12:44:12 +0200 Message-ID: <1686503.Zkmt1EvEu4@thomas> In-Reply-To: References: <20200319171907.60891-1-ciara.power@intel.com> <8682539.rMLUfLXkoz@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 23/04/2020 12:30, Luca Boccassi: > On Thu, 2020-04-09 at 11:37 +0200, Thomas Monjalon wrote: > > 09/04/2020 11:19, Bruce Richardson: > > > 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. > > > > Yes, this is a new idea. > > Throwing the idea in this "telemetry" thread and in "IF proxy" thread > > is the first step before starting a dedicated thread to design > > a generic mechanism. > > May I offer the services of https://zeromq.org/ ? This is what I already proposed: http://inbox.dpdk.org/dev/20334513.huCnfhLgOn@xps/ I'm sorry, I was supposed to start a new thread for this discussion. I will summarize my thoughts and discussions just after -rc1 is done.