09/11/2018 09:28, Tom Barbette: > Hi ethdev maintainers, > > > Support of drivers for the fields in rte_eth_stats is a bit random, and never > mentioned in the doc. A quick survey showed me : > > > ipackets : implemented by all drivers > ibytes : all except null, ring > ierror : all except af_packet, ark, avf, axgbe, fm10k, kni, null, pcap, ring, > szedata2, vhost > imissed : *only* af_packet, avp, axgbe, fm10k, kni, liquidio, mlx4, mlx5, > null, pcap, ring, szedata2, tap, vhost, virtio > rx_nombuf : *only* > bnx2x,bnxt,bonding,ena,enic,failsafe,mlx4,mlx5,netvsc,nfp,qede,szedata2,tap,virtio > > With no way to know if we can rely on the value or not, as a DPDK user pov. > The only way to know if we can rely on a given counter is to grep the driver > code. Except if I missed something? > > Also the doc of rte_eth_stats_get only mention io packets, bytes and errors. > Not the other fields, and the way it is written let the reader think it is > always supported if the function does not return 0. > > I can update the doc to reflect the state of things. But maybe we could make > that function return a bitmask which tells which counter has been set. But > that would break the ABI... We could also have the bitmask set through a > passed pointer, so it does not break code checking the return value is 0. Or > maybe have the bitmask elsewhere, like for the offloads? Which fields are > supported is probably a constant. So that may make more sense.
I think having capabilities, as for offload, is reasonnable. The other option would be to push for implementing all basic stats in all drivers, and consider an unimplemented stat as a bug.
