On Wednesday 24 May 2006 10:01, Phil Dibowitz wrote:
David Miller wrote:
Some time in the next few weeks, it is likely that the 2.6.18
merge window will open up shortly after a 2.6.17 release.
So if you have major 2.6.18 submissions planned for the networking,
you need to start
The current patch is fine if your hardware implements the required atomicity
itself.
Near all do optionally, but it would make increasing the statistics a magnitude
more expensive.
Atomic operations don't come cheap on modern systems. And you would need
to change the fast path increments
Can you ask internally on how openview would handle this? It carriers
the major chunk of management tools market so it may provide good
insight.
I've asked the question in an internal, informal communications channel.
No guarantees it will reach any OpenView types, but if it does I'll try
Phil Dibowitz wrote:
As for the clearing, in this case, the clearing is done by a command to
the hardware - and I believe the hardware does that atomically. However,
I could certainly add a spinlock around it if someone sees a need.
No, because then you'd also have to add the spin-lock in the
On Wed, 24 May 2006, Jeff Garzik wrote:
Brent Cook wrote:
Note that this is just clearing the hardware statistics on the interface,
and
would not require any kind of atomic_increment addition for interfaces that
support that. It would be kind-of awkward to implement this on drivers
On Wed, 24 May 2006, Phil Dibowitz wrote:
Right. I think the point here is that it does _NOT_ inherently break
things. If you don't like the behavior, don't run ethtool -z eth0,
it's that simple.
A co-worker suggested today, that maybe it'd appease people if the final
ethtool patch made it
On Wed, 24 May 2006, Phil Dibowitz wrote:
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding
Phil Dibowitz [EMAIL PROTECTED] :
[...]
Right. I think the point here is that it does _NOT_ inherently break
things. If you don't like the behavior, don't run ethtool -z eth0,
it's that simple.
It would be better to explain why several sysadmins want this feature
and why it can't be done in an
On Thursday 25 May 2006 02:23, Bill Fink wrote:
On Wed, 24 May 2006, Jeff Garzik wrote:
Brent Cook wrote:
Note that this is just clearing the hardware statistics on the
interface, and would not require any kind of atomic_increment addition
for interfaces that support that. It would be
On Thu, 2006-05-25 at 03:23 -0400, Bill Fink wrote:
likely problem areas. The human mind (at least speaking for myself) is
not nearly as adept when having to deal with deltas. Yes, you can record
the initial state of all the devices, run the stress test, record the new
state of all the
On Wed, 2006-24-05 at 13:25 -0700, Rick Jones wrote:
The lanadmin (think ethtool) command of HP-UX has had a way to clear the
statistics reported by lanadmin. I do not know however, if that affects
the stats in the actual SNMP interface MIBs as I've never had occasion
to look.
I still
On Thu, 25 May 2006, Brent Cook wrote:
On Thursday 25 May 2006 02:23, Bill Fink wrote:
On Wed, 24 May 2006, Jeff Garzik wrote:
Brent Cook wrote:
Note that this is just clearing the hardware statistics on the
interface, and would not require any kind of atomic_increment addition
Can you ask internally on how openview would handle this? It carriers the
major chunk of management tools market so it may provide good insight.
I've asked the question in an internal, informal communications channel.
No guarantees it will reach any OpenView types, but if it does I'll
try to
On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
I'll admit to not knowing all the intricacies of the kernel coding
involved, but I don't offhand see how zeroing the stats would be
significantly more complex than updating the stats during normal usage.
But I'll have to leave
On Thursday 25 May 2006 12:59, Phil Dibowitz wrote:
On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
I'll admit to not knowing all the intricacies of the kernel coding
involved, but I don't offhand see how zeroing the stats would be
significantly more complex than updating the
From: Phil Dibowitz [EMAIL PROTECTED]
Date: Thu, 25 May 2006 12:22:39 -0700
So at least, for the _current_ implimentations, this should have no
performance impacts.
Regardless, I think this is something that userspace _can_
take care of reasonably and therefore has no buisness in the
kernel.
From: Phil Dibowitz [EMAIL PROTECTED]
Date: Thu, 25 May 2006 14:04:12 -0700
why would specifically not support a _feature_ of the hardware.
Sparc64 chips support a hash table like hw assist feature for TLB
reloading, I didn't use it for 8+ years and went with a virtual page
table approach
David Miller wrote:
Some time in the next few weeks, it is likely that the 2.6.18
merge window will open up shortly after a 2.6.17 release.
So if you have major 2.6.18 submissions planned for the networking,
you need to start thinking about getting it to me now.
There is a 2.6.18 tree up
On Wed, 2006-24-05 at 01:01 -0700, Phil Dibowitz wrote:
[..]
For your reference, here's the two times I've posted it this month - I'm
happy to send it along again.
The problem with resetting stats is it is _most definetely_ going to
break management apps like SNMP.
This is not to say this
Those folks wanting link-level stats over an interval (I'm assuming that
is wny someone would want to zero stats?) should feel free to embrace
and extend beforeafter:
ftp://ftp.cup.hp.com/dist/networking/tools/
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding operations other than
'increment' or
Phil Dibowitz wrote:
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding operations other
On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote:
Phil Dibowitz wrote:
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
On Wednesday 24 May 2006 14:14, Phil Dibowitz wrote:
On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote:
Phil Dibowitz wrote:
Given any method of clearing statistics across your cluster, I'm certain
you can come up with a similar method of obtaining the current statistic
(the
On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
Right, I'm aware there are other ways of doing this - I've written scripts to
record a hundreds of numbers, and then subtract them from each other. But
those scripts are work arounds
It is not a work around, _it is design intent_. It
Brent Cook wrote:
Note that this is just clearing the hardware statistics on the interface, and
would not require any kind of atomic_increment addition for interfaces that
support that. It would be kind-of awkward to implement this on drivers that
increment stats in hardware though (lo, vlan,
Can you provide some link to a vendor that allows resetting ethernet
stats? I am almost certain, if they do they will have something or other
which indicates that such a reset happened. It is also easier for cisco
to have none standard feature as of ios 15.16 which could support such
behavior
jamal wrote:
On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
Right, I'm aware there are other ways of doing this - I've written scripts to
record a hundreds of numbers, and then subtract them from each other. But
those scripts are work arounds
I don't have any problem with Phil's
On Wed, May 24, 2006 at 04:10:32PM -0400, jamal wrote:
Can you provide some link to a vendor that allows resetting ethernet
stats? I am almost certain, if they do they will have something or other
which indicates that such a reset happened. It is also easier for cisco
to have none standard
On Wed, 2006-05-24 at 14:23 -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing,
iptables -Z
often because adding operations other than
So how is this different than if an SNMP station probes my system, then
I reboot, then they probe again. Things will seem to have gone
backwards, but they deal with that just fine.
In that case hasn't the system's uptime and/or last boot time in the MIB
changed and so indicates to the
Phil Dibowitz wrote:
Well, I can show you support on my home switch (cabletron) - the network guys
will be a little unhappy if I clear stats on our production network (cisco)
without warning them:
Isn't that last bit an example of why it might not be good to play-out
that rope?-)
Does
Rick Jones wrote:
Phil Dibowitz wrote:
Does having the ability to boot into single user mode break
networking? No, it
*allows* you to break networking. Does the _support_ of rmmod break the
kernel? No, but it *allows* you to.
Are SNMP traps generated by going into single-user mode?
Brian Haley wrote:
I don't have any problem with Phil's changes.
Thanks Brian, and Andy, and Ben for your support and ideas.
So how is this different than if an SNMP station probes my system,
then I reboot, then they probe again. Things will seem to have gone
backwards, but they deal with
34 matches
Mail list logo
