[dpdk-dev] Future Direction for rte_eth_stats_get()

[David Harton (dharton)]

> > 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

Thanks for sharing.  I do think what is in the link is well thought out but it also may not match how the application would choose to represent that stat (capitalization, abbreviation, etc).

> 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.

I understand it may be broken, but that doesn't help finding them and ensuring they aren't broken to begin with.  What regression/automation is in place to ensure drivers aren't broken?

> 
> 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.

100% agree.  I can see the intent.

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

I think parsing strings is expensive CPU wise and again subject to error as devices are added.  That's why I was wondering if a binary id could be generated instead.  The binary id could also be used to look up the string name if the application wants it.  The API would be very similar to the current xstats API except it would pass id/value pairs instead of string/value pairs.  This avoids string comparisons to figure out while still allowing flexibility between drivers.  It would also 100% guarantee that any strings returned by "const char* rte_eth_xstats_str_get(uint32_t stat_id)" are consistent across devices.

I also think there is less chance for error if drivers assign their stats to ID versus constructing a string.  I haven't checked my application, but I wonder if the binary size would actually be smaller if all the stats strings were centrally located versus distributed across binaries (highly dependent on the linker and optimization level).

> 
> 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?

Appreciate the offer.  I actually understand what's is available.  And, BTW, I apologize for being late to the game (looks like this was discussed last summer) but I'm just now getting looped in and following the mailer but I'm just wondering if something that is performance friendly for the user/application and flexible for the drivers is possible.

Thanks,
Dave

> 
> 
> Regards, -Harry