> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton > Sent: Thursday, November 3, 2016 3:01 AM > > On 02/11/2016 17:07, Mcnamara, John wrote: > [..] > > Perhaps we could an API that returns a struct, or otherwise, that > > indicated what stats are returned by a PMD. An application that > > required stats could call it once to establish what stats were > > available. It would have to be done in some way that wouldn't break > > ABI every time a new stat was added. > > > > Harry, Remy, how would this fit in with the existing stats scheme or > > the new metrics library. > > At the moment xstats (rte_eth_xstats_get()) pulls stuff out of > rte_eth_stats and reports them unconditionally alongside all the > driver-specific xstats. This could change so that it only reports the > (legacy) stats the PMDs actually fills in. > > Personally in the longer term I think xstats should get all the info it > requires directly rather than relying on the legacy stats for some of > its info, but that would involve pushing a lot of common code into the > PMDs.. > > ..Remy
Adding eth_stats to eth_xstats or not is not important - it's not a synchronized snapshot of the entire counter set, just a question of calling one or two functions to obtain the values. Regarding eth_xstats, I would dare to say that the NIC HW designers chose their statistics counters wisely, based on a combination of industry standards (e.g. common SNMP MIBs, such as the Interfaces MIB and etherStats) and customer feedback, so the hardware counters are probably useful to a DPDK application, and thus it makes sense to expose them directly. The application can transform them into industry standard counter sets (IF-MIB, etherStats, etc.) if required. DPDK could offer a common library for this transformation. -Morten
