On Wed, Jun 17, 2015 at 9:58 AM, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote: [...] > > You are extending the generic stats. This is not the idea behind xstats. > The xstats are specific to the driver. > Furthermore we should migrate some "not really generic stats" to xstats > in order to keep only the really basic and common stats in rte_eth_stats. > By the way, in order to avoid duplicated code when getting generic stats > through xstats API, we need to change the implementation of > rte_eth_xstats_get() to add generic stats automatically, even if the > driver provide some xstats.
This may be the wrong thread for this, and perhaps this question has been answered (I couldn't find anything relating to it), but I have a related question regarding exposing stats that are not captured in the current device independent api (rte_eth_stats_get). Is there a recommended strategy for displaying MIB interface stats for applications using DPDK? For example, consider the IF-MIB (http://www.ietf.org/rfc/rfc2233.txt). It provides three "normal" in packet counters: ifHCInUcastPkts ifHCInMulticastPkts ifHCInBroadcastPkts Looking at rte_eth_stats, the structure returned by rte_eth_stats_get, we can only retrieve the total number of in packets, and the total number of in multicast packets. We can't retrieve the number of in broadcast packets. This means that we neither display ifHCInUcastPkts (which needs us to subtract mulicast and broadcast from the total), nor ifHCInBroadcastPkts. While I understand that some devices may not support classifying packets into such categories, I would think that most NICs would try to allow applications to conform the fairly established standards such as the IF-MIB. One would think that maybe xstats would allow this: these nics have low level stats that provide this information. However, consumers of the API would need to understand each NIC's implementation of the xstats API to use it, making it somewhat cumbersome to use. I'd think that it makes sense for the MIB information to live in a device-independent, well-defined API. Does it make sense to provide sufficient information in the eth_stats_get function to provide support for the various interface stats mibs? Alternatively, does it make sense to make a new function or API tailored to providing this support? It could be device independent (unlike xstats), while allowing each driver to choose whether or not it supports it. I'm using a fairly old version of DPDK (1.7.1), but from looking at the master branch (http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.h), it looks like the structure hasn't really changed. I've been struggling to figure out the right away to approach this, so any thoughts/insights would be much appreciated. Thanks, Kyle
