RFC: another approach for 64-bit network stats

This patch implements a lockless aproach for 64-bit netstatistics with 
only a very rare
racecondition. On 64 bit system, nothing is changed. On 32 bit system 
the (32bit) counter
is checked periodically for overflows. The overflows are saved in 
counter_high. To detect
overflows, we need to save the counter value when last checked 
(counter_last), so there is
a 4byte overhead per 64bit counter. The 32-bit values can be accessed as 
before through
stats->counter, the 64bit values are accessed through a macro 
NETSTAT64(stats, counter).
Accessing the 64bit values contains the before mentioned race-condition, 
when the counters
are synced while they are read and an overflow occured the value could 
be of 4gb. However
the next read will return the correct value and with gigabit speed we 
only need to sync every ~30s,
so thats much better than racing on every counter update (using 64bit 
counters directly) and
potentially damaging the counter permanently. The race could be avoided 
by locking syncs and
reads (not normal counter updates). The patch only breaks binary 
interfaces, all in-kernel users
can continue to use the 32bit values until they have been changed, 
userspace software just
needs recompilation, device drivers don't need any changes at all.

Comments ?

Bye,
Patrick

If you don't want to poll periodically for network stats, as has
been repeatedly suggested, you can always poll periodically for the
64-bit NIC-specific stats that most gige adapters provide these days,
using ethtool.  NIC-specific stats also tend to provide more fine
granularity than the current net_device_stats members.

	Jeff

Patrick McHardy wrote:

This patch implements a lockless aproach for 64-bit netstatistics with 
only a very rare
racecondition. On 64 bit system, nothing is changed. On 32 bit system 

I think that you should consider providing a new API as opposed to
breaking existing APIs.

And, perhaps this new API could deal with the very rare race to make
it never happen?  No matter how rare it is, you still have to write code
to work around it if it exists..might as well do it once in the kernel
instead of making each user of the interface deal with it.

Personally, I'd like to see the net-device stats (64-bit or otherwise) available
through the ethtool interface in a well defined binary package (perhaps a
struct net_device_stats, or similar.)

Ben



-- 
Ben Greear [off-list ref]       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 07 July 2003 12:53, Ben Greear wrote:

I think that you should consider providing a new API as opposed to
breaking existing APIs.

Do you mean reworking the network statistics side of networking?

Jeff.

- -- 
Please avoid sending me Word or PowerPoint attachments.
 See http://www.fsf.org/philosophy/no-word-attachments.html 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Ca77wFP0+seVj/4RArtOAJwNVhV9PNgyli/d93n4ocCaRZzxmACeMdr8
9W0vfMOt76DNXq2t4Phoye0=
=8LGV
-----END PGP SIGNATURE-----