From: Bill Fink <billfink@mindspring.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
James Cammarata <jimi@sngx.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH] net: add ability to clear stats via ethtool - e1000/pcnet32
Date: Sun, 1 Jun 2008 23:55:58 -0400 [thread overview]
Message-ID: <20080601235558.66e1ed7b.billfink@mindspring.com> (raw)
In-Reply-To: <20080601222906.GH30769@solarflare.com>
On Sun, 1 Jun 2008, Ben Hutchings wrote:
> Bill Fink wrote:
>
> > But the question
> > is how does one devise a generic script or tool that doesn't require
> > any special knowledge of the specific NIC being used. For example,
> > here's the "ethtool -S" info for my myri10ge NIC:
> >
> > [root@chance8 ~]# ethtool -S eth2
> > NIC statistics:
> [...]
> > WC: 1
> > irq: 8413
> > MSI: 1
> > read_dma_bw_MBs: 1398
> > write_dma_bw_MBs: 1613
> > read_write_dma_bw_MBs: 2711
> > serial_number: 287046
> [...]
> > tx_linearized: 0
> > link_changes: 8
> > link_up: 1
> [...]
> >
> > How does one know which of these reported values are counter stats
> > that one wishes to zero/snapshot, and which are not?
>
> Ah, I see, I didn't realise some drivers were abusing ethtool stats in
> this way. But for the most part the differences will show up as zeroes.
I'm not sure I would characterize that as abuse of the ethtool stats,
but rather just a different category of stats. And I wouldn't want
them to show up as zeros after doing a clear/snapshot of the counter
stats. The "ethtool -S" output should be completely normal afterward,
with just the counter stats being zeroed.
> If there's really a need for ethtool stats that aren't counters,
> maybe the ethtool API should include flags to indicate which they are.
That would be useful. Maybe some way of determining the type of an
ethtool stat such as COUNTER (perhaps with subtypes for signed versus
unsigned, 32-bit versus 64-bit), RUNTIME_INFO, etc.
> > Another issue that occurred to me is if multiple people are working
> > on troubleshooting a network problem, how do we insure that they all
> > get a consistent view of the stats? If this is done via a kernel
> > mechanism then there isn't an issue. But if it's done via user space,
> > then you have to make sure that everyone zeros/snapshots the stats
> > at the same time.
> >
> > Ideally, one should be able to do something like "ethtool -z ethX"
> > to zero/snapshot the driver stats, and then "ethtool -S ethX" to get
> > the stats since the last snapshot. You should be able to use the
> > same tool ("ethtool") to do all of this, and not some other special
> > tool or specially devised homegrown script. Why make users lives
> > any more difficult than need be?
>
> No-one's stopping you from adding these options to ethtool. You could
> have it save statistic sets in, say, /var/run/ethtool.
Yes, that could be done if the ability to determine which ethtool stats
were counter stats was added to the ethtool API. And I guess they
should be saved in something like /var/run/ethtool/ethX. But then
what happens when you start using multiple network namespaces, and
for example have eth0 in several different network namespaces. How
could that be handled, to keep the different network namespaces from
clobbering the stats of another namespace? If done in the kernel,
I believe it would all work as expected, but it's not clear to me
how to handle this in user space.
-Bill
next prev parent reply other threads:[~2008-06-02 3:56 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 15:18 [PATCH updated] net: add ability to clear per-interface network statistics via procfs James Cammarata
2008-05-16 16:20 ` Eric Dumazet
2008-05-16 20:03 ` David Miller
2008-05-17 14:54 ` James Cammarata
2008-05-17 21:41 ` Eric Dumazet
2008-05-17 22:49 ` James Cammarata
2008-05-18 0:31 ` Ben Hutchings
2008-05-18 1:43 ` Patrick McHardy
2008-05-18 5:09 ` James Cammarata
2008-05-18 11:27 ` Ben Hutchings
2008-05-29 1:45 ` [PATCH] net: add ability to clear stats via ethtool - e1000/pcnet32 James Cammarata
2008-05-29 2:08 ` James Cammarata
2008-05-29 5:11 ` Andrew Morton
2008-05-29 12:34 ` James Cammarata
2008-05-29 14:45 ` Alan Cox
2008-05-29 17:15 ` James Cammarata
2008-05-29 20:50 ` David Miller
2008-05-29 21:18 ` James Cammarata
2008-05-30 19:12 ` Bill Fink
2008-05-30 22:14 ` Rick Jones
2008-05-31 1:09 ` Bill Fink
2008-05-31 2:41 ` Stephen Hemminger
2008-05-31 4:47 ` Bill Fink
2008-05-31 12:11 ` Alan Cox
2008-05-31 23:57 ` Bill Fink
2008-06-01 1:46 ` Ben Hutchings
2008-06-01 20:46 ` Bill Fink
2008-06-01 22:29 ` Ben Hutchings
2008-06-02 3:55 ` Bill Fink [this message]
2008-06-02 5:39 ` David Miller
2008-06-02 15:41 ` Bill Fink
2008-06-02 4:50 ` Glen Turner
2008-06-02 16:10 ` Bill Fink
2008-06-03 12:28 ` James Cammarata
2008-06-03 12:35 ` Ben Hutchings
2008-06-03 14:46 ` Alan Cox
2008-06-04 3:05 ` James Cammarata
2008-05-29 14:48 ` Chris Friesen
2008-05-16 20:00 ` [PATCH updated] net: add ability to clear per-interface network statistics via procfs David Miller
2008-05-16 20:09 ` Rick Jones
2008-05-17 15:06 ` James Cammarata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080601235558.66e1ed7b.billfink@mindspring.com \
--to=billfink@mindspring.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bhutchings@solarflare.com \
--cc=jimi@sngx.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox