Do not seemingly #include Linux-specific headers on other platforms.

Until now, the OVS source tree has had a whole maze of header files that
make "#include <linux/openvswitch.h>" work OK regardless of platform, but
this confuses everyone new to the tree, at first glance, and is difficult
to understand at second glance too.

This commit renames include/linux/openvswitch.h to
datapath/linux/compat/include/linux/openvswitch.h without other change,
then modifies the userspace build to generate a header that makes sense in
portable Open vSwitch userspace from that header.

It then removes all the remaining include/linux/* files since they are now
unused.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
odp-netlink.h: Use 32-bit aligned 64-bit types.

Open vSwitch userspace uses special types to indicate that a particular
object may not be naturally aligned.  Netlink is one source of such
problems: in Netlink, 64-bit integers are often aligned only on 32-bit
boundaries.  This commit changes the odp-netlink.h that is transformed from
<linux/openvswitch.h> to use these types to make it harder to accidentally
access a misaligned 64-bit member.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
ofproto-dpif: Use DPIF_FP_CREATE but not DPIF_FP_MODIFY.

A dpif reports EEXIST if a flow put operation that should create a new flow
instead attempts to modify an existing flow, or ENOENT if a flow put would
create a flow that overlaps some existing flow.  The latter does not always
indicate a bug in OVS userspace, because it can also mean that two
userspace OVS packet handler threads received packets that generated
the same megaflow for different microflows.  Until now, userspace has
logged this, which confuses users by making them suspect a bug.  We could
simply not log ENOENT in userspace, but that would suppress logging for
genuine bugs too.  Instead, this commit drops DPIF_FP_MODIFY from flow
put operations in ofproto-dpif, which transforms this particular
problem into EEXIST, which userspace already logs at "debug" level (see
flow_message_log_level()), effectively suppressing the logging in normal
circumstances.

It appears that in practice ofproto-dpif doesn't actually ever need to
modify flows in the datapath, only create and delete them, so this
shouldn't cause problems.

Suggested-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
ofproto-dpif: fix an ovs crash when dpif_recv_set returns error

When dpif_recv_set returns an error, close_dpif_backer gets called,
which in term calls recirc_id_pool_destroy, which can lead to a crash
since recirc_id_pool_create() was not called before this patch.

Reported-by: Mukesh Hira <mhira@vmware.com>
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Fix tests broken by previous commit.

This fixes tests that were broken by commit a7d1bbdcfe (ofproto-dpif: Use
DPIF_FP_CREATE but not DPIF_FP_MODIFY.)

Signed-off-by: Ben Pfaff <blp@nicira.com>
dpctl: add ovs-appctl dpctl/* commands to talk to dpif-netdev

This commit introduces multiple appctl commands (dpctl/*)

They are needed to interact with userspace datapaths (dpif-netdev), because the
ovs-dpctl command runs in a separate process and cannot see the userspace
datapaths inside vswitchd.

This change moves most of the code of utilities/ovs-dpctl.c in lib/dpctl.c.

Both the ovs-dpctl command and the ovs-appctl dpctl/* commands make calls to
lib/dpctl.c functions, to interact with datapaths.

The code from utilities/ovs-dpctl.c has been moved to lib/dpctl.c and has been
changed for different reasons:
   - An exit() call in the old code made perfectly sense. Now (since the code
     can be run inside vswitchd) it would terminate the daemon. Same reasoning
     can be applied to ovs_fatal_*() calls.
   - The lib/dpctl.c code _should_ not leak memory.
   - All the print* have been replaced with a function pointer provided by the
     caller, since this code can be run in the ovs-dpctl process (in which
     case we need to print to stdout) or in response to a unixctl request (and
     in this case we need to send everything through a socket, using JSON
     encapsulation).

The syntax is
   ovs-appctl dpctl/(COMMAND) [OPTIONS] [PARAMETERS]
while the ovs-dpctl syntax (which _should_ remain the same after this change)
is
   ovs-dpctl [OPTIONS] (COMMAND) [PARAMETERS]

Signed-off-by: Daniele Di Proietto <ddiproietto@vmware.com>
[blp@nicira.com made stylistic and documentation changes]
Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-appctl: Add logging options.

Normally I would also add documentation for the logging options to the
ovs-appctl manpage, but I am concerned that in this case it would actually
make the manpage confusing, because one of the main purposes of ovs-appctl
is to modify the log levels of *other* programs, and these options only
modify the log level of ovs-appctl itself, which is rarely useful.

The following commit will start using these logging options in a test.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ansis Atteka <aatteka@nicira.com>
tests: Turn off appctl poll_loop logging for long output.

One of the VMware internal autobuilder builds failed due to extraneous
logging in these tests of the form:

   2014-07-28T21:11:07Z|00001|poll_loop|INFO|wakeup due to [POLLIN] on fd 3
   (...) at lib/stream-fd-unix.c:124 (93% CPU usage)

I think this must be because these tests have tons of output and so on a
loaded machine it can take some CPU to pull it down.  We don't want to fail
for that reason, so disable this logging.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ansis Atteka <aatteka@nicira.com>
INSTALL.Windows: Update build instructions to do 'make'.

We no-longer need to build individual targets on Windows. This information
was lost when we committed the hyper-v changes to the repo.

Resurrecting that information in this change.

Also, added the testing instructions on how to setup a VLAN based network.

Signed-off-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
datapath-windows: Rename solution name.

extensions.sln is the name of the MS sample solution.

Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Nithin Raju <nithin@vmware.com>
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>
style: Replace TODO with XXX.

In accordance with CodingStyle.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ovs-dev.py: Support check-valgrind in the Makefile.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>