sFlow: clear the padding

putString pads the string to the 4-byte boundary without
clearing the "padded" memory. This patch simply set the
padding to zero.

Signed-off-by: Francesco Fusco <ffusco@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
netlink: Update comment for nl_dump_start().

The function comment still referred to a 'msg' variable, which has been
renamed.

Signed-off-by: Joe Stringer <joestringer@nicira.com>
[blp@nicira.com did further proofreading]
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-upcall: Avoid unnecessarily installing datapath flows.

handle_upcalls() always installed a flow for every packet, as long as
the datapath didn't already have too many flows, but there are cases where
we don't want to do this:

    - If we get multiple packets in a single microflow all in one batch
      (perhaps due to GSO breaking up a large TCP packet for sending to
      userspace, or for another reason), then we only need to install the
      datapath flow once.

    - For a slow-pathed flow received via a slow-path action in the kernel,
      we know that the kernel flow is already there (because otherwise it
      would have been received as "no match" instead of an action), so
      there is no benefit to reinstalling it.

Noticed because a CFM slow-pathed flow was getting reinstalled every time
a CFM packet was received.

Reported-by: Guolin Yang <gyang@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
tunnel: Un-wildcard only flags that really exist in tnl_xlate_init().

The revalidator code in ofproto-dpif-upcall.c, in revalidate_ukey(),
deletes any datapath flow for which the kernel reports wildcarded bits
that userspace requires to be matched.  Until now, tnl_xlate_init() marked
every bit in the tunnel flags as required to be matched.  Since most of
those bits don't actually have defined flags, adding such a flow to the
datapath and then receiving it back caused those bits to become wildcarded,
which meant that revalidate_ukey() always deleted them.

This fixes the problem by only un-wildcarding defined flags.

Reported-by: Guolin Yang <gyang@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Un-wildcard nw_frag only for protocols that have fragments.

The revalidator code in ofproto-dpif-upcall.c, in revalidate_ukey(),
deletes any datapath flow for which the kernel reports wildcarded bits
that userspace requires to be matched.  Until now, a couple of pieces of
code in ofproto-dpif always marked nw_frag (which tracks whether a packet
is an IPv4 or IPV6 fragment) as exact-match.  For non-IP protocols, this
wasn't meaningful, so adding such a flow to the datapath and then receiving
it back caused nw_frag to become wildcarded, so revalidate_ukey() always
deleted them.

This fixes the problem by only un-wildcarding nw_frag for protocols where
it is defined (IPv4 and IPv6).

Noticed while observing CFM traffic (which isn't IP based) over a tunnel.

Reported-by: Guolin Yang <gyang@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
rhel: Enable DHCP support for internal ports.

The current initscripts ifup-ovs brings up internal ports as
an ordinary ethernet device, so BOOTPROTO=dhcp|none does not
consider any OVS/bridge detail.

Since DHCP requires a port in the bridge to reach the server,
bring up the required port before in the same way it does for
OVS bridge.

Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
util: Set program_name for windows correctly.

Windows path uses backward slashes. Also, the executable name
has a .exe extension in it. While creating log files, we use
the program name to create log file names. It feels a little odd
to have log file names like ovsdb-server.exe.log etc. Using
_splitpath_s() is a way to have same log file names on both
windows and linux platforms.

Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
ovs-thread: Add new support for thread-specific data.

A couple of times I've wanted to create a dynamic data structure that has
thread-specific data, but I've not been able to do that because
PTHREAD_KEYS_MAX is so low (POSIX says at least 128, glibc is only a little
bigger at 1024).  This commit introduces a new form of thread-specific data
that supports a large number of items.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
fat-rwlock: New big but fast synchronization primitive.

This implements a reader-writer lock that uses a lot of memory (128 to 192
bytes per thread that takes the lock) but avoids cache line bouncing when
taking the read side.  Thus, a fat_rwlock is a good choice for rwlocks
taken frequently by readers.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
classifier: Use fat_rwlock instead of ovs_rwlock.

Jarno Rajahalme reported up to 40% performance gain on netperf TCP_CRR with
an earlier version of this patch in combination with a kernel NUMA patch,
together with a reduction in variance:
    http://openvswitch.org/pipermail/dev/2014-January/035867.html

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