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