Fix strict aliasing violations with GCC 4.1 and 4.4.

The typical use of struct sockaddr_storage is flagged as a strict
aliasing violation by GCC 4.4.7.  Using an explicit union lets the
compiler know that accessing the same location via different types is
not an error.

GCC 4.1.2 had a similar complaint about a cast of ukey's key_buf to
nlattr.  After this patch there are no further warnings with the
XenServer build, so we could start treating warnings as errors in the
builds.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/ovs-atomic: Elaborate memory_order documentation.

The definition of memory_order_relaxed included a compiler barrier,
while it is not necessary, and indeed the following text on
atomic_thread_fence and atomic_signal_fence contradicted that.

memory_order_consume and memory_order_acq_rel are also more thoroughly
described.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/ovs-atomic: Require memory_order be constant.

Compiler implementations may provide sub-optimal support for a
memory_order passed in as a run-time value (ref.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html).

Document that OVS atomics require the memory order to be passed in as
a compile-time constant.

It should be noted, however, that when inlining is disabled (i.e.,
compiling without optimization) even compile-time constants may be
passed as run-time values to (non-inlined) functions.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ovs-atomic: Fix GCC4+ atomic_flag.

The default memory order for atomic_flag is documented to be
memory_order_seq_cst (as in C11), but the GCC4+ implementation only
used the GCC builtins, which provide acquire and release semantics
only.  Additional barriers are needed for in other cases.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/ovs-atomic-gcc4+: Use 'volatile' to enforce memory access.

Use 'volatile' to enforce a new memory access on each lockless atomic
store and read.  Without this a loop consisting of an atomic_read with
memory_order_relaxed would be simply optimized away.  Also, using
volatile is cheaper than adding a full compiler barrier (also) in that
case.

This use of a volatile cast mirrors the Linux kernel ACCESS_ONCE macro.

Without this change the more rigorous atomic test cases introduced in
a following patch will hang due to the atomic accesses being optimized
away.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
tests/test-atomic: Cover more of the atomic API.

This adds tests using all of the defined memory orders, as well as
simple two-thread test cases for the acquire-release and
consume-release patterns.

These new tests helped uncover a bug in the ovs-atomic-gcc4+
implementation, which was fixed in a preceding patch.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/ovs-atomic: Native support for x86_64 with GCC.

Some supported XenServer build environments lack compiler support for
atomic operations.  This patch provides native support for x86_64 on
GCC, which covers possible future 64-bit builds on XenServer.

Since this implementation is faster than the existing support prior to
GCC 4.7, especially for cmap inserts, we use this with GCC < 4.7 on
x86_64.

Example numbers with "tests/test-cmap benchmark 2000000 8 0.1" on
quad-core hyperthreaded laptop, built with GCC 4.6 -O2:

Using ovs-atomic-pthreads on x86_64:

Benchmarking with n=2000000, 8 threads, 0.10% mutations:
cmap insert:   4725 ms
cmap iterate:   329 ms
cmap search:   5945 ms
cmap destroy:   911 ms

Using ovs-atomic-gcc4+ on x86_64:

Benchmarking with n=2000000, 8 threads, 0.10% mutations:
cmap insert:    845 ms
cmap iterate:    58 ms
cmap search:    308 ms
cmap destroy:   295 ms

With the native support provided by this patch:

Benchmarking with n=2000000, 8 threads, 0.10% mutations:
cmap insert:    530 ms
cmap iterate:    59 ms
cmap search:    305 ms
cmap destroy:   232 ms

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/ovs-atomic: Native support for 32-bit 586 with GCC.

XenServer runs OVS in dom0, which is a 32-bit VM.  As the build
environment lacks support for atomics, locked pthread atomics were
used with considerable performance hit.

This patch adds native support for ovs-atomic with 32-bit Pentium and
higher CPUs, when compiled with an older GCC.  We use inline asm with
the cmpxchg8b instruction, which was a new instruction to Intel
Pentium processors.  We do not expect anyone to run OVS on 486 or older
processor.

cmap benchmark before the patch on 32-bit XenServer build (uses
ovs-atomic-pthread):

$ tests/ovstest test-cmap benchmark 2000000 8 0.1
Benchmarking with n=2000000, 8 threads, 0.10% mutations:
cmap insert:   8835 ms
cmap iterate:   379 ms
cmap search:   6242 ms
cmap destroy:  1145 ms

After:

$ tests/ovstest test-cmap benchmark 2000000 8 0.1
Benchmarking with n=2000000, 8 threads, 0.10% mutations:
cmap insert:    711 ms
cmap iterate:    68 ms
cmap search:    353 ms
cmap destroy:   209 ms

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>