64-bit fields in struct net_device_stats
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I was looking for a project that would take some time to finish, and I think
I found it - converting all code in the kernel to use u_int64_t (or similar) instead of unsigned long in struct net_device_stats.
Now, I have an idea on my mind about how to do this:
I'd move the structure to a new file in linux/include/asm (linux/include/asm-{arch}/netdevice.h, for example) and implement there couple of functions that would change the counters in the structure (something like: static inline void net_stats_txbytes_add(struct net_device_stats* stats, unsigned long len)). These would lock (if necessary
- - 32-bit architectures), add, unlock (if necessary.) The only thing is, that all the NIC drivers in the kernel up to date would have to be changed to use this new interface.
Now, my question: Is there a better way of accomplishing this?
Thanks,
Jeff.
- --
A CRAY is the only computer that runs an endless loop in just 4 hours... -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+7R3XwFP0+seVj/4RAolgAJ9QE4eLfKqrVhR9tktoZCHjcfarfgCcDb1A HELhBfYleUbTSaTymmTsRJM=
=xu4t
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 15 June 2003 21:30, Jeff wrote:
<snip>
Quoted 2 lines
These would lock (if
necessary - 32-bit architectures), add, unlock (if necessary.)
<snip>
I now realize, that locking is out of the question. Also, it has been suggested to use per cpu stats and overflow into a global counter. (Thanks Zwane) This might be a better idea - the problem is, the counter won't be 100% accurate at all times. The degree of inaccuracy will vary with the threshold value. On the other hand, if the threshold is relatively low, no one will notice the difference these days.
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+7TEswFP0+seVj/4RAidcAJ0UAgHtRK4F1HHp8vOSLVOc5tdtRgCfXTyN MA5sBYybdjJxwxAwtiUnE8I=
=MbW+
-----END PGP SIGNATURE-----
Quoted 1 line · Jeff
I now realize, that locking is out of the question. Also, it has been
Well spinlocks in particular would be particularly ugly here and cause horrid cache line ping pong. Other methods of synchronization would have to be looked at.
Quoted 5 lines
suggested to use per cpu stats and overflow into a global counter. (Thanks Zwane) This might be a better idea - the problem is, the counter won't be 100% accurate at all times. The degree of inaccuracy will vary with the threshold value. On the other hand, if the threshold is relatively low, no one will notice the difference these days.
This would be one method of doing updates and for stats it would be fine, however feel free to look into other ways...
Zwane
Signature · 1 line
function.linuxpower.ca
Quoted 8 lines · Zwane Mwaikambo
Quoted 1 line · Jeff
I now realize, that locking is out of the question. Also, it has been
Well spinlocks in particular would be particularly ugly here and cause horrid cache line ping pong. Other methods of synchronization would have to be looked at.
Quoted 8 lines
Quoted 5 lines
suggested to use per cpu stats and overflow into a global counter. (Thanks Zwane) This might be a better idea - the problem is, the counter won't be 100% accurate at all times. The degree of inaccuracy will vary with the threshold value. On the other hand, if the threshold is relatively low, no one will notice the difference these days.
This would be one method of doing updates and for stats it would be fine, however feel free to look into other ways...
Looking closer i'd say go for it, there isn't a real locking issue, if you're looking for something to do this should be rather fun with not that much breakage, of course you'd also have to update some userland tools/utilities.
have fun,
Zwane
Signature · 1 line
function.linuxpower.ca
A message that is not in the archive (sent off-list or not yet received): [email protected]
nde.com
Quoted 8 lines · Zwane Mwaikambo
Quoted 5 lines
suggested to use per cpu stats and overflow into a global counter. (Thanks Zwane) This might be a better idea - the problem is, the counter won't be 100% accurate at all times. The degree of inaccuracy will vary with the threshold value. On the other hand, if the threshold is relatively low, no one will notice the difference these days.
This would be one method of doing updates and for stats it would be fine, however feel free to look into other ways...
why not a set of counters which are toggled between.
e.g.
struct netdevice... {
uint64 tx_pkts_counter[2];
uint64 tx_octets_counter[2];
uint64 rx_pkts_counter[2];
uint64 rx_octets_counter[2];
int counter_bounce;
...
}where readers simply do something like:
tx_bytes +=
netdevice[foo]->tx_octets_counter[(netdevice[foo]->counter_bounce)];
and writer(s) alternate between updating one uint64 and an alternate one?
in this manner, you don't need to do any special synchronization or atomic updates or have any dependency on any particular architecture being able to do atomic 64-bit ops.
cheers,
lincoln.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 11 lines · Lincoln Dale
why not a set of counters which are toggled between.
e.g.
struct netdevice... { uint64 tx_pkts_counter[2]; uint64 tx_octets_counter[2]; uint64 rx_pkts_counter[2]; uint64 rx_octets_counter[2]; int counter_bounce; ... }
<snip>
Hmm, interesting idea. The one thing is: There are 23 fields in struct net_device_stats right now; if each of them is 64bits (=8 bytes), the whole structure would be 184 bytes (with u_int64.) Now if I have two of each, the size would grow to 368 bytes (plus the 4 bytes for counter_bounce). Now, the
question: would it be acceptable to have something that size?
Jeff.
- --
*NOTE: This message is ROT-13 encrypted twice for extra protection* -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+7c4FwFP0+seVj/4RAtGxAJsE+YY48y1mp+Y90FFH2Jz+hmU+fgCeK+gj 6ksJ8KxDYVo7rwxODwSAeT8=
=Sxo5
-----END PGP SIGNATURE-----