DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Tyler Retzlaff <roretzla@linux.microsoft.com>,
	dev@dpdk.org, dmitry.kozliuk@gmail.com,
	navasile@linux.microsoft.com, ciara.power@intel.com
Subject: Re: [dpdk-dev] [PATCH v2] metrics/windows: build rte_metrics library
Date: Wed, 20 Jan 2021 13:13:46 +0100	[thread overview]
Message-ID: <2157928.aXkhnrQ3pi@thomas> (raw)
In-Reply-To: <20210120115408.GC1406@bricha3-MOBL.ger.corp.intel.com>

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.



  reply	other threads:[~2021-01-20 12:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 23:37 [dpdk-dev] [PATCH] " Tyler Retzlaff
2021-01-12  1:15 ` Dmitry Kozlyuk
2021-01-12  1:32   ` Tyler Retzlaff
2021-01-12  6:44     ` Tal Shnaiderman
2021-01-12  1:30 ` [dpdk-dev] [PATCH v2] " Tyler Retzlaff
2021-01-17 22:19   ` Thomas Monjalon
2021-01-19 21:31     ` Tyler Retzlaff
2021-01-19 21:52       ` Thomas Monjalon
2021-01-20 10:37         ` Bruce Richardson
2021-01-20 11:09           ` Thomas Monjalon
2021-01-20 11:54             ` Bruce Richardson
2021-01-20 12:13               ` Thomas Monjalon [this message]
2021-01-20 13:57                 ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2157928.aXkhnrQ3pi@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=ciara.power@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=navasile@linux.microsoft.com \
    --cc=roretzla@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).