Re: Future Direction for rte_eth_stats_get()
From: Kyle Larose <hidden>
Date: 2016-02-02 13:47:03
On Tue, Feb 2, 2016 at 7:44 AM, Tahhan, Maryam [off-list ref] wrote:
quoted
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.quoted
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
I also agree about the ifTable/ifXTable. I think that a few other ethernet oriented MIBs may also be worth considering. The RMON MIB's etherStatsTable has some useful counters in it (namely, the packet size histogram counters). We could also do the dot3StatsTable from the EtherLike MIB, though I'm not sure how useful it would be.
quoted
From long experience, this inconsistency is quite annoying when trying to make very accurate traffic measurements in network management software. Matthew.