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

["David Harton (dharton)" <dharton@cisco.com>]

> From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]
> 
> > 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

Apologies Harry!  I didn't see your original post because the IT gods had decided your response was "Junk" mail and it didn't make it to my dev_dpdk.org mail folder. :(

A colleague actually pointed me to this post separately today.  I've made the Junk mailer a little smarter now...hopefully.

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

Yes, after thinking about it more I think it could get crazy.

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

Actually, I put a fair bit of thought into things and then realized, why re-invent the wheel?
Why not follow the ethtool stats model?

struct rte_eth_xstats_name {
    char name[RTE_ETH_XSTATS_NAME_SIZE]; };

extern int rte_eth_xtats_count(uint8_t port_id, unsigned *count);
extern int rte_eth_xtats_strings(uint8_t port_id, unsigned count, struct rte_eth_xtats_name *names);
extern int rte_eth_xtats_values(uint8_t port_id, unsigned count, uint64_t *values);

The existing API could be left in-place and these could be added for folks that don't want to grab the strings all the time.

The cons compared to providing an enum or extending struct rte_eth_stats are:
 - you have to perform a query immediately after the device is attached
 - doesn't require conformity...which has pros and cons

I'm actually testing the changes above if folks think this would be a reasonable compromise I can patch them up.

I still feel the feedback myself and others gave about rte_eth_stats_get() being closer to a standard MIB should get some consideration.  Applications that run with a number of different drivers/device types likely want to avoid having to create "xstats mapping tables" every time a new device pops out just so they can debug problems.

Thanks,
Dave