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 that argument to the experts. > > > > What it boils down to is that currently, a single CPU or thread ever touches > the stats concurrently, so it doesn't have to lock them or do anything > special to ensure that the continue incrementing. If you want to make sure > that the statistics actually reset when you want them to, you have to account > for this case: > > CPU0 reads current value from memory (increment) > CPU1 writes 0 to current value in memory (reset) > CPU0 writes incremented value to memory (increment complete)
Perhaps I'm missing something here, but these counters are only incrimented in hardware... i.e. attomically. And the reset I do is via a command register, which should also be atomic. Now in a driver that was keeping this all in a local struct, I could understand that need for locking, but in the skge case, and in fact in many drivers I've looked at, the numbers are all kept in the hardware, incremented by the hardware, as it gets packets. So clearing them via command registershouldn't need locking as far as I can tell. But please, correct me if I'm wrong. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759
signature.asc
Description: Digital signature
