Re: [PATCH] macvlan: lockless tx path

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mercredi 10 novembre 2010 à 14:53 -0800, Ben Greear a écrit :

> I did similar, and then wrote extra code to detect a 64-bit kernel and if
> so assume that the counters wrap at 64 bits so I didn't have to poll so
> often to make sure I didn't miss a wrap for a 10G NIC.  If instead one wraps at 33
> bits and the other at 36, there is no way for me to deal with the wrap
> properly w/out explicitly knowing about that 33 and 36.
> 

How do you define 'wrap around' ? Maybe your definition is wrong.

> If the old 32-bit counters in /proc/net/dev instead had a driver that
> managed to wrap them at 28 bits, I can't see how your application could
> have worked properly, so you must have been assuming that the kernel would
> always return a full 32-bit counter.

I suggest you take a look at various SNMP applications that handle this
just fine. RRD for example. You can patch your favorite driver to cap
the stats to 37, 38, ... 31 or 30 bits, it works.

If you sample values faster than half the period, it works.

This has nothing to do with 32 or 64 bits, really.

Read RFC1230 for a good advice


	All the statistics are defined using the
        syntax Counter as 32 bit wrap around
        counters.  Thus, if an interface's
        hardware chip set maintains these
        statistics in 16-bit counters, then the
        agent must read the hardware's counters
        frequently enough to prevent loss of
        significance, in order to maintain
        a 32-bit counter in software."

Yes, 16bit counters _are_ fine, even if provided in a 32bit counter, if
you read value fast enough.