> From: Thomas Monjalon [mailto:thomas.monjalon at 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
