On Mon, 14 Sep 2020 19:33:08 +0000 Saeed Mahameed wrote: > > +Protocol-specific statistics > > +---------------------------- > > + > > +Some of the interfaces used for configuring devices are also able > > +to report related statistics. For example ethtool interface used > > +to configure pause frames can report corresponding hardware > > counters:: > > + > > + $ ethtool --include-statistics -a eth0 > > + Pause parameters for eth0: > > + Autonegotiate: on > > + RX: on > > + TX: on > > + Statistics: > > + tx_pause_frames: 1 > > + rx_pause_frames: 1 > > + > > this will require to access the HW twice per stats request to read both > stats and current parameters, maybe this is not a big deal, but sharp > accuracy can be important for some performance enthusiasts. > > Do we need an API that only reports statistics without the current > parameters ?
That crossed my mind. IDK how real this concern is if we have ethtool -S which dumps half of the universe and nobody ever done anything about it.. Once we start adding more interfaces (as I said elsewhere I plan to add FEC counters) we'll also have to do multiple calls for multiple types of stats. But I think that's fine as a starting point. We can extend RTM_GETSTATS to provide an efficient interface when needed. As you may recall a couple years back I posted a set with "hierarchical stats" which as an attempt to solve all the problems at once. I concluded that it's a wrong approach. We should start with the simple and obvious stuff. We can build complexity later.
