[dpdk-dev] Future Direction for rte_eth_stats_get()

[Tahhan, Maryam]

> From: David Harton (dharton) [mailto:dharton at cisco.com]
> Sent: Friday, February 5, 2016 9:16 PM
> To: Van Haaren, Harry <harry.van.haaren at intel.com>; Thomas
> Monjalon <thomas.monjalon at 6wind.com>
> Cc: dev at dpdk.org; Tahhan, Maryam <maryam.tahhan at intel.com>;
> Mcnamara, John <john.mcnamara at intel.com>
> Subject: RE: [dpdk-dev] Future Direction for rte_eth_stats_get()
> 
> 
> > 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 think this is a reasonable compromise. 

> I still feel the feedback myself and others gave about rte_eth_stats_get()
> being closer to a standard MIB should get some consideration.
 +1

> 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