> 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