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]
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:16 EST