On Mon, 2020-09-14 at 12:52 -0700, Jakub Kicinski wrote: > 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.
Agreed.
