Re: [dpdk-dev] Future Direction for rte_eth_stats_get()

["Van Haaren, Harry" <harry.van.haaren@intel.com>]

> From: David Harton
> 
> enum rte_eth_stat_e {
>     /* accurate desc #1 */
>     RTE_ETH_STAT_1,
>     /* accurate desc #2 */
>     RTE_ETH_STAT_2,
> ...
> }
> struct rte_eth_id_stat {
>     rte_eth_stat_e id;
>     uin64_t value;
> }
> 
> int rte_eth_id_stats_num(uint8_t port_id, uint32_t *num_stats);
> /* returns < 0 on error or the number of stats that could have been read (i.e. if userd
> */
> int rte_eth_id_stats_get(uint8_t port_id, uint32_t num_stats, rte_eth_id_stat *id_stats);
> const char* rte_eth_id_stat_str(rte_eth_stat_e id);
> 
> This allows a driver to return whatever stats that it supports in a consistent manner and
> also in a performance friendly way.  In fact, the driver side would be identical to what
> they have today but instead of having arrays with "string stat name" they will have the
> rte_eth_stat_e.


Thanks for the code and explanation.


> > RE: Thomas asking about performance numbers:
> > I can scrape together some raw tsc data on Monday and post to list, and we
> > can discuss it more then.
> 
> I can do the same if desired.  But, just to make sure we are discussing the same issue:
> 
> 1) call rte_eth_xtats_get()
> This will result in many string copies and depending on the driver *many* copies I don't
> want or care about.
> 2) "tokenize"/parse/hash the string returned to identify what the stat actually is
> I'm guessing you are stating that this step could be mitigated at startup.  But, again, I
> don't think the API provides a guarantee which usually leads to bugs over time.
> 3) Copy the value of the stat into the driver agnostic container the application uses
> 4) Repeat steps 1-3 for every interface being serviced every 5 or 10 secs
> 
> Contrast that to my suggestion which has no string copies and a compile time mapping
> between "stat_id" and "app stat" can be created for step 2.  I think the performance
> differences are obvious even without generating cycle times.


Indeed using integers will reduce overhead compared to
strings, and the helper function to convert the integer
to string provides the same possibilities as the current
API (in a different way).

I haven't collected performance data yet, apologies for
the delay. Perhaps continuing this conversation after the
V1 patch deadline at the end of the week is a good idea?
I'll have more time to dedicate to thinking about this.


-Harry