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>