Date:	Thu, 11 Nov 2010 08:40:58 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] macvlan: lockless tx path

On 11/10/2010 11:03 PM, Eric Dumazet wrote:
> Le mercredi 10 novembre 2010 à 15:46 -0800, Ben Greear a écrit :
>> On 11/10/2010 03:36 PM, Eric Dumazet wrote:
>>> 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.
>>
>> Maybe so.  My algorithm looks like:
>>
>>    // uint64 accum;
>>    // uint32 old;
>>    // uint32 new;
>>    if (old>  new) {
>>        // This assumes counters wrap at 32 bits (ie, 0xFFFFFFFF).
>>        accum += ((uint32)(0xFFFFFFFF) - old) + new;
>>    }
>>    else if (old<  new) {
>>        accum += new - old;
>>    }
>>    old = new;
>>
>> ...
>>
>> Is there some way I can do this w/out the (0xFFFFFFFF - old),
>> and thus the assumption of 32-bit counters?
>>
>
> Yes, please take a look at RRD for an example, then you can adapt to
> your needs.
>
> <quote>
>
> http://www.mrtg.org/rrdtool/tut/rrdtutorial.en.html
>
> At the time of writing this document, RRDtool knows of counters that are
> either 32 bits or 64 bits of size. These counters can handle the
> following different values:
>
>   - 32 bits: 0 ..           4294967295
>   - 64 bits: 0 .. 18446744073709551615
>
> If these numbers look strange to you, you can view them in their
> hexadecimal form:
>
>   - 32 bits: 0 ..         FFFFFFFF
>   - 64 bits: 0 .. FFFFFFFFFFFFFFFF
>
> RRDtool handles both counters the same. If an overflow occurs and the
> delta would be negative, RRDtool first adds the maximum of a small
> counter + 1 to the delta. If the delta is still negative, it had to be
> the large counter that wrapped. Add the maximum possible value of the
> large counter + 1 and subtract the erroneously added small value.
>
> There is a risk in this: suppose the large counter wrapped while adding
> a huge delta, it could happen, theoretically, that adding the smaller
> value would make the delta positive. In this unlikely case the results
> would not be correct. The increase should be nearly as high as the
> maximum counter value for that to happen, so chances are you would have
> several other problems as well and this particular problem would not
> even be worth thinking about. Even though, I did include an example, so
> you can judge for yourself.

So, they assume counters are exactly 32 or 64 bits.
Your example of the 36-bit counter would break their
assumptions of 32 or 64 bits.

I agree that you can guess if the counter is 32 or 64, at least with today's
hardware and relatively normal poll times, and the requirement that the
counters can ONLY be 32 or 64 bits.  I still consider it a kludge to
return 32 bit counters in stats64, however.  Would you consider
a patch to have netlink pay attention to whether the stats are 32 or
64 (based on a flag returned from dev_get_stats perhaps)?

Thanks,
Ben


-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

--
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