Re: reminder, 2.6.18 window...

[Phil Dibowitz <phil@ipom.com>]

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

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 that just fine.

Right. Reboots, rmmod/modprobe's, etc. can all cause this. Most
management interfaces seem to handle such things.

> DEC/Compaq/HP has allowed this on Tru64 UNIX since 1999 because we had
> customers that wanted it, noone ever complained about complications
> with SNMP.  We did save the last time the stats were zero'd in the
> struct for posterity, but that was never get-able via SNMP:
...
> Maybe saving a "ztime" would make people happier?

I could certainly do this. It would of course change the structure
making the patch slightly more invasive, but it people want this, I can
do it.

Andy wrote:
> 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

Good call - I forgot about that.

Ben Greear wrote:
>> Are SNMP traps generated by going into single-user mode?  Rather like
>> what I was saying to Brian earlier.   I suspect though that an rmmod
>> doesn't generate an SNMP trap - unless perhaps that to do the rmmod
>> one has to first ifdown the interface and that might?
> 
> If the interface comes back, it will (may?) have a different device id
> (if-index),
> even if the name is the same.

Right - but most GUI management interfaces I've seen key off of
interface name *not* ifindex. Certainly Cacti, which I use, does.

> Regardless, not everyone uses SNMP, so clearing stats can still be
> useful.  Even
> if it is not implemented perfectly (ie, no locking, so it's possible
> that a clear
> will not totally clear some stats), it will still be right most of the
> time, and
> that will help the casual user who is trying to diagnose network errors
> with only
> console access to the system... (ie, ifconfig -a).

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 a capitol option that you can only run by itself.
I.e. if you can't call it with anything else, it's more difficult to
call my accident. I'd be willing to this.

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.

-- 
Phil Dibowitz                             phil@ipom.com
Freeware and Technical Pages              Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind."
 - Dr. Seuss



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]