Mark J Roberts wrote:> Chris Wedgwood:>>>total_rx_bytes += rx_bytes;>>>>if lval is 64-bit, then this cannot be done reliably on all>>architectures> > > I'm not sure why. I realize that x86 can't do atomic 64-bit> operations, but what I propose is to leave the 32-bit rx_bytes code> the way it is, and just have some heuristic for updating the 64-bit> value every so often, which can be done under a lock, so there would> be no opportunity for races to corrupt the counter. (This is also an> optimization since there needn't be any locks in the actual packet> handling code.)

I was one of the ones who was interested in making the statistics 64-bit, and adding locking to do it right. The solution finally appeared, many months ago:

The counters don't need to be 64-bit, because it is trivially possible for userspace to track the statistics, and to simply use the difference between two samples as the increment used in calculating whatever numbers you wish -- 64-bit SNMP MIB statistics were what I was interested in. Wrapping is trivially handled by standard unsigned int arithmetic, among other methods.

If you really want the raw data, then use ethtool's NIC-specific stats facility, to retrieve raw statistics directly from the NIC. [this of course requires driver modifications, but they are easy on modern NICs]