Re: [dpdk-dev] [PATCH v2] metrics/windows: build rte_metrics library

[Thomas Monjalon <thomas@monjalon.net>]

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.