I understand. Is this the reason that that strings were used to identify the xstat types? An enum type would be much more efficient instead of doing string copies when retrieving the stats, but the number of enum entries would quickly grow out of control as device specific stats were added.
In this case, I'm actually referring to the stats that are common to all NICs. For example, for the received fragmented packets counter, there are three strings that identify this value: rx_fragment_packets (igb), rx_fragment_errors (ixgbe), rx_fragmented_packets (i40e). I was thinking of making those names consistent. Perhaps the reason why they were different in the first place is that each of the device datasheets refers to these exact names. Tom -----Original Message----- From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: Wednesday, October 28, 2015 5:32 PM To: Tom Crugnale Cc: Harry van Haaren; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 00/11] Port XStats On Wed, 28 Oct 2015 17:35:09 +0000 Tom Crugnale <tcrugnale at sandvine.com> wrote: > Hi Harry, > > We are planning on using the xstats API for periodic stats collection through > a polling thread. This would be done in a generic NIC agnostic manner, which > would require that the xstats identifiers have consistent naming amongst all > of the NIC types. It would likely be polled several times per second and > would only gather a subset of all available xstats types. > > I have reviewed your patches and am interested in providing some API > enhancements and bugfixes. Are you willing to provide feedback on such > changes? > > Thank you, > Tom The whole point of xstats is to allow device specific statistics. Consistent use of names is good from a user interface point of view, but probably not a hard requirement.
