[ovs-dev] [PATCH] upcall: Allow max_idle be configured through ovs-vsctl.

Joe Stringer joestringer at nicira.com
Tue Feb 18 19:00:04 UTC 2014


On 14 February 2014 11:17, Jarno Rajahalme <jrajahalme at nicira.com> wrote:
>
> Access to a shared variable that may change concurrently without any sort
> of synchronization should be atomic to protect against "tearing", where the
> reader gets a mixture of the old and new versions of the variable. This
> could happen for a "long int" on a 32-bit platform (if, e.g., the 8 bytes
> span a cache line boundary). Atomic access to a variable for which this can
> not happen (e.g., aligned 32-bit int on a 32-bit CPU) compiles to normal
> memory access, so there is no overhead.
>
> In practice it is safe to assume that for an aligned "int" or any pointer
> this will not be a problem, so why not make the ofproto_max_idle an int
> instead of long long int?


This case had slipped my mind, the only motivation for 'long long int' was
that this is the type we use for time in general. Given that we already
limit the valid values for this variable, and to address this particular
issue, I plan to send out a v3 using unsigned instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140218/2172e14a/attachment-0005.html>


More information about the dev mailing list