[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <483EE4A4.20508@sngx.net>
Date: Thu, 29 May 2008 12:15:16 -0500
From: James Cammarata <jimi@...x.net>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: 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
> For one quite a few of the network cards keep the stats in hardware and
> don't neccessarily have a way to reset them. In other cases there is a
> mix of OS accumulated stats bulk updated by overflow events on the device
> itself.
Yes, and there's no good way to get around that, so the best thing for that
hardware would probably to not add this functionality, in which case ethtool
would simply report that it's not available.
> Its a lot of complexity, and changes all over the places for the sake of
> a trivial userspace change. I would suggest you instead write a quick bit
> of perl or python that fetches the stats and then updates every second
> with the changes.
I would disagree with you on the complexity issue. In general, it is one
new function (trivial in length) and an addition to the ethtool ops. SNMP
and sar cover the reporting needs, but there have been multiple times when
troubleshooting under the gun that this would have been extremely useful
to help diagnose the issue (in one instance, we were getting floods of
jumbo frames and other errors, and we did not know how quickly they were
accumulating, because the switch was not seeing the same problem). My day
job is in the financial industry, so we are often under very short SLA's
to diagnose issues, and having this built into the kernel/existing tools
would be a boon. I'd be more than happy to change this to a kernel config
option, experimental and default off for those who would not want it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists