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.
