Date:	Sun, 1 Jun 2008 23:55:58 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Cammarata <jimi@...x.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: add ability to clear stats via ethtool -
 e1000/pcnet32

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@...nce8 ~]# 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists