[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1289432184.17691.141.camel@edumazet-laptop>
Date: Thu, 11 Nov 2010 00:36:24 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ben Greear <greearb@...delatech.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] macvlan: lockless tx path
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists