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 E4CF4A0A05; Wed, 20 Jan 2021 13:13:51 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A2C30140D06; Wed, 20 Jan 2021 13:13:51 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id AFE0C140D03 for ; Wed, 20 Jan 2021 13:13:50 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 275CF5C0164; Wed, 20 Jan 2021 07:13:50 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 20 Jan 2021 07:13:50 -0500 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=fm3; bh= MSrCnDGMEUljkEiVmJs3xQAI/skLnuogTCQwlO5aQo4=; b=ly1uIRz256JdBGK/ OCnwMBJ+UcvVYYXnN9qz0G7/ai7qGLmXy6M5mXRDFqPasTQdkrrf9Gua5v/YSmXp 5TrDiO8LSpZ5NCwA3fui0c/Jps/ECquBcnge08TFvQ/6Yz9l+WSVLdR9C/SEEFga m4pJl3iffjmPd1DV0QTE+Q9fDyUQmB0I5Pz0GXw4dTKrj9O1rkHOnSdKVnzCcGcR sB+IoelREoWpcVVpvC1as6KMs4SkJ3KYIyrOs4cpO8/GcIOybhm7jMU81QK+iHwc DwYE6WNe+5DcXdohvtqJiY4fqN+7kTxBxq+44Ve0YOwo71KmXpmKc0njV4P8ygey XnBK0g== 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=fm1; bh=MSrCnDGMEUljkEiVmJs3xQAI/skLnuogTCQwlO5aQ o4=; b=N7HOeHUi5P0LSGd0/svq2CP/4KCMkV/xOprA3APKBzDFhqdJvGZhsMB3+ R9HK/sX7utRTwrTGrrJi9PXglxd7aERDl09AAn2RMCeE1nFkZRieYjkJcSbXMWoe PgO+J80BFDudFcoTZmfQycn+ziokCY5ukAcKDIIkCrSRwn0znahuYGeQFoS15CzS DCM90NckwyMqeb1lX35kW5Ad427aJSE7zimlwkMH1zYM1T7R/Lc1LYoVwARt5wCk tzM9OMvbZUEdwKRilbPOY4iXYGiY4bq/yI/bLF+juVvnJZNxpKVCtJ8Nm3A02ads 3utuQA5JoJhEPSWW7OAuDgqzZknmg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 D57021080063; Wed, 20 Jan 2021 07:13:48 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson Cc: Tyler Retzlaff , dev@dpdk.org, dmitry.kozliuk@gmail.com, navasile@linux.microsoft.com, ciara.power@intel.com Date: Wed, 20 Jan 2021 13:13:46 +0100 Message-ID: <2157928.aXkhnrQ3pi@thomas> In-Reply-To: <20210120115408.GC1406@bricha3-MOBL.ger.corp.intel.com> References: <1610408246-29482-1-git-send-email-roretzla@linux.microsoft.com> <3646223.fRS4d9ebDi@thomas> <20210120115408.GC1406@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] metrics/windows: build rte_metrics library 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" 20/01/2021 12:54, Bruce Richardson: > On Wed, Jan 20, 2021 at 12:09:19PM +0100, Thomas Monjalon wrote: > > 20/01/2021 11:37, Bruce Richardson: > > > On Tue, Jan 19, 2021 at 10:52:03PM +0100, Thomas Monjalon wrote: > > > > 19/01/2021 22:31, Tyler Retzlaff: > > > > > On Sun, Jan 17, 2021 at 11:19:55PM +0100, Thomas Monjalon wrote: > > > > > > > > > > > > Not sure it makes sense without the new telemetry feature. > > > > > > Please focus on telemetry lib instead of half-enabling > > > > > > the old metrics lib. > > > > > > > > > > > > > > > > can you elaborate? (or reference a mailing list discussion) that gives some > > > > > guidance? > > > > > > > > > > is the telemetry lib a replacement for metrics? the component we have now > > > > > relies on the non-telemetry functions exported from metrics but does not > > > > > use the telemetry functions. > > > > > > > > > > also, i notice that the meson.build for telemetry lib has an include path > > > > > that references rte_metrics but does not appear to actually include any of > > > > > the headers from rte_metrics (vestigial? missed in previous cleanup perhaps?) > > > > > > > > I think Bruce and Ciara will better explain than me > > > > the intent of the telemetry lib and the compatibility path with the metrics lib. > > > > > > > > > > The include path addition for metrics to the telemetry library does indeed > > > look like it was just missed being removed, since I can compile things up > > > successfully with it removed. > > > > > > With regards to interaction between telemetry library and metrics library, > > > they are complementary but not replacements for each other. The metrics > > > library provides support for tracking metrics, mostly on a per-port basis. > > > The original telemetry library implementation was based on top of the > > > metrics library and supported reporting out data from that library. More > > > recent versions of the telemetry library have reworked that support to > > > allow the reporting of arbitrary telemetry data, not just from the metrics > > > library, but the old interface is still supported. > > > > The question is what is available in rte_metrics which is not already > > available with rte_telemetry only? > > I think rte_metrics is used only for rte_bitratestats and rte_latencystats. > > Can we use rte_telemetry for this and forget rte_metrics? > > > No, we can't. > In short, metrics is a data store. Telemetry is a data output mechanism. > > Telemetry cannot directly replace metrics because it does not store any > data, it simply matches incoming requests against callbacks to retrieve and > export data. The actual management of the underlying data sources is the > responsibility of the library/app which has registered the callback. > > Metrics, on the other hand, is a data storage library, and allows the > registration of groups of statictics which can be tracked and updated. It > does also provide some callbacks to allow the data to be output by > telemetry, but this functionality is not the primary goal of the lib. Both > bitratestats and latencystats use metrics to manage their stats data - > again any output provided is incidental to the primary purpose. When you say "we can't", you mean it is not a desirable addition? I am fine with keeping the design as is, split in libs.