Re: Future Direction for rte_eth_stats_get()

From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()

+ Harry

Hey all,

xstats are driver agnostic and have a well-defined naming scheme.

Indeed, described here:
http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html#extended-statistics-api

All of the rte_eth_stats statistics are presented in xstats consistently
(independent of which PMD is running), as they are implemented in rte_ethdev.c:
http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n1500


From: David Harton:

For example, what if there was a kind of "stats registry" composed of ID and name.  It
would work similar to xtats except instead of advertising strings only the "get" API would
return ID/count pairs.  If the application wishes to use the DPDK provided string they can
call another API to get the stat string via the ID.  These IDs would be well-defined
clearly explaining what the count represent.  This way the strings for counts will be
uniform across drivers and also make it clear to the users what the counts truly represent
and the application could obtain stats from any driver in a driver agnostic manner.

What you (David Harton) describe about a well-defined name, and clearly explaining the value
it is representing is what the goal was for xstats: a human readable string, which can be
easily parsed and a value retrieved.

The "rules" of encoding a statistic as an xstats string are pretty simple, and if any PMD
breaks the rules, it should be considered broken and fixed.

Consistency is key, in this case consistency in the PMD xstats implementations to make it
useful for clients of the API.

The big advantage xstats has over adding items to rte_eth_stats is that it won't break ABI.

Do you see a fundamental problem with parsing the strings to retrieve values?

If you like I could code up a minimal sample-app that only pulls statistics,
and you can show "interest" in various statistics for printing / monitoring?


Regards, -Harry