[ovs-dev] [dpif-netdev 05/15] dpif-netdev: Use new "ovsthread_counter" to track dp statistics.

Jarno Rajahalme jrajahalme at nicira.com
Tue Dec 31 00:44:45 UTC 2013


On Dec 30, 2013, at 4:10 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Mon, Dec 30, 2013 at 03:55:01PM -0800, Jarno Rajahalme wrote:
>> 
>> On Dec 30, 2013, at 3:32 PM, Ben Pfaff <blp at nicira.com> wrote:
>> 
>>> In the end, my goal here is to provide a useful abstraction and a
>>> simple implementation that is likely to be correct.  Then, later, if
>>> profiling shows that this is an actual bottleneck, we can optimize
>>> it.  But I don't want to spend a bunch of time optimizing code that I
>>> don't even know is important.
>> 
>> Would using a single atomic int be worse than using an array of
>> locks? At least it would be simpler and obviously correct?
> 
> An atomic_uint would be easy, but the hit and miss and lost counts can
> easily overflow UINT_MAX after a while.  atomic_ullong isn't portable,
> unfortunately.
> 
> Maybe I will skip the whole controversy and just add a mutex around
> these variables.  It might be slow, but it might not be the bottleneck
> initially, and it would be obviously correct.
> 
> What do you guys think?

How about adding an OVS wrapper for atomic_ullong with a mutex-based fallback implementation? Would be nice, especially if a native implementation exists on some of the most used compilers/targets (?)

  Jarno




More information about the dev mailing list