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

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

+John,

> From: David Harton 
> Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
> 
> Hi folks,
> 
> I didn't see any follow up to this response.

I think you may have missed one:
http://dpdk.org/ml/archives/dev/2016-January/032211.html


> <snip>
> However, if modifying that API is not desired then I'd
> really like to have some feedback about extending the current xstats model.

API / ABI modification/breakage is something that will
need to be considered in any discussions. The 2.3 (or 16.04)
V1 patch deadline has passed, so any output from this 
discussion will be leading to the 16.07 release.

> Again, it is desired not to have to copy and/or parse strings for scalability reasons but
> still maintain the "ABI flexibility" for which the xstats model was geared towards.

Agreed.


From: David Harton
> enum rte_eth_stat_e {
>     /* accurate desc #1 */
>     RTE_ETH_STAT_1,
>     /* accurate desc #2 */
>     RTE_ETH_STAT_2,
> ...
> }

For this enum, do you see each stat for every PMD entered here?
RX_GOOD_PACKETS,

What about RX and TX, is it listed twice?
RX_GOOD_PACKETS,
TX_GOOD_PACKETS,

In a case where a VF has RX_GOOD_PACKETS, does it get its "own" set?
RX_GOOD_PACKETS,
TX_GOOD_PACKETS,
VF_RX_GOOD_PACKETS,
VF_TX_GOOD_PACKETS,

I'm looking at the enum thinking it will grow out of control.
Have you thought about adding metadata for RX / TX, PF / VF?

If metadata info is added, it would make retrieving a set of
statistics based on a certain mask much easier. Do you think
this may be of use?


-Harry