[dpdk-dev] Future Direction for rte_eth_stats_get()

[Tahhan, Maryam]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
> Sent: Friday, January 22, 2016 8:49 PM
> To: Igor Ryzhov <iryzhov at nfware.com>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Future Direction for rte_eth_stats_get()
> 
> On Fri, Jan 22, 2016 at 06:02:24PM +0300, Igor Ryzhov wrote:
> > How about exposing stats according to IF-MIB?
> >
> > Statistics to be exposed are - octets, unicast packets, multicast
> > packets, broadcast packets, errors and discards for both TX and RX.
> >
> > These counters are basic and implemented by most of drivers.
> 
> To be a bit more specific it would be good to have IF-MIB ifTable with
> the items from ifXTable as well:
> 

I think the MIBs ifTable would be good for the high level stats across all the drivers for sure, we would need to take backward compatibility for the current stats into account. 

> ifIndex
> ifMtu
> ifHighSpeed
> ifPromiscuousMode
> ifPhysAddress
> ifConnectorPresent
> 
> ifHCInOctets
> ifHCInUcastPkts
> ifHCInMulticastPkts
> ifHCInBroadcastPkts
> ifInDiscards
> ifInErrors
> ifInUnknownProtos
> 
> ifHCOutOctets
> ifHCOutUcastPkts
> ifHCOutMulticastPkts
> ifHCOutBroadcastPkts
> ifOutDiscards
> ifOutErrors
> 
> A number of things are missing or weird in the DPDK stats interface.
> Then I get stuck trying to maintain them in my app instead and it's
> annoying.
> 
> Also, it is nice to get the struct populated atomically so the values are as
> self-consistent as possible. If you have to call a function separately on
> each stat it makes them self-inconsistent because it is less atomically
> populated.

+1
> 
> From long experience, this inconsistency is quite annoying when trying to
> make very accurate traffic measurements in network management
> software.
> 
> Matthew.