Re: Future Direction for rte_eth_stats_get()

From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matthew Hall
Sent: Friday, January 22, 2016 8:49 PM
To: Igor Ryzhov <redacted>
Cc: dev@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:

quoted

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.