[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200914125210.3b230a32@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 14 Sep 2020 12:52:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Saeed Mahameed <saeedm@...dia.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"mkubecek@...e.cz" <mkubecek@...e.cz>,
Tariq Toukan <tariqt@...dia.com>,
"michael.chan@...adcom.com" <michael.chan@...adcom.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"alexander.duyck@...il.com" <alexander.duyck@...il.com>,
"andrew@...n.ch" <andrew@...n.ch>
Subject: Re: [PATCH net-next v2 2/8] docs: net: include the new ethtool
pause stats in the stats doc
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.
Powered by blists - more mailing lists