[lkml]   [2003]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Annoying /proc/net/dev rollovers.
    Mark J Roberts wrote:
    > Chris Wedgwood:
    >>>total_rx_bytes += rx_bytes;
    >>if lval is 64-bit, then this cannot be done reliably on all
    > 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]


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.022 / U:123.716 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site