Re: Future Direction for rte_eth_stats_get()

On Fri, Jan 22, 2016 at 9:22 AM, Van Haaren, Harry <
harry.van.haaren@intel.com> wrote:

quoted

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

quoted

+ Harry

Hey all,

quoted

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:

quoted

For example, what if there was a kind of "stats registry" composed of ID

and name.  It

quoted

would work similar to xtats except instead of advertising strings only

the "get" API would

quoted

return ID/count pairs.  If the application wishes to use the DPDK

provided string they can

quoted

call another API to get the stat string via the ID.  These IDs would be

well-defined

quoted

clearly explaining what the count represent.  This way the strings for

counts will be

quoted

uniform across drivers and also make it clear to the users what the

counts truly represent

quoted

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?

When you have an appliance with a large number of ports and a large number
of stats that you need to collect, having to parse those strings constantly
is very slow compared to having fixed struct members or at least known ID
values.

Strings are also error prone. While they may be consistent at this point,
it is remarkably easy for them to get out of sync along the way. Using an
ID instead avoids that neatly.

Jay