man-pages: Add missing entry for matching metadata

Signed-off-by: Joe Stringer <joe@wand.net.nz>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Do not include zeroed metadata fields in NXM/OXM packet-in messages.

NXM and OpenFlow 1.2+ allow including the values of arbitrary flow metadata
in "packet-in" messages.  Open vSwitch has until now always included all
the values of the metadata fields that it implements in NXT_PACKET_IN
messages.

However, this has at least two disadvantages:

    - Most of the metadata fields tend to be zero most of the time, which
      wastes space in the message.

    - It means that controllers must be very liberal about accepting
      fields that they know nothing about in packet-in messages, since any
      switch upgrade could cause new fields to appear even if the
      controller does nothing to give them nonzero values.  (Controllers
      have to be prepared to tolerate unknown fields in any case, but this
      property makes unknown fields more likely to appear than otherwise.)

This commit changes Open vSwitch so that metadata fields whose values are
zero are not reported in packet-ins, fixing both problems.  (This is
explicitly allowed by OpenFlow 1.2+.)

This commit mainly fixes a sort of internal conceptual dissonance centering
around struct flow_metadata.  This structure is supposed to report the
metadata for a given flow.  If you look at a flow, it has particular
metadata values; it doesn't have masks, and the idea of a mask for a
particular flow doesn't really make sense.  However, struct flow_metadata
did have masks.  This led to internal confusion; one can see this in, for
example, the following code removed by this commit in ofproto-dpif.c to
handle misses in the OpenFlow flow table:

    /* Registers aren't meaningful on a miss. */
    memset(pin.fmd.reg_masks, 0, sizeof pin.fmd.reg_masks);

What this code was really trying to say is that on a flow miss, the
registers are zero, so they shouldn't be included in the packet-in message.
It did manage to omit the registers, by marking them as "wild", but it is
conceptually more correct to simply omit them because they are zero (and
that's one effect of this commit).

Bug #12968.
Reported-by: Igor Ganichev <iganichev@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofp-util: Drop unneeded null pointer tests.

The functions being called already do nothing if passed a null pointer.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ofp-print: Fix memory leak printing flow stats replies.

Found by valgrind.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ovs-ofctl: Fix memory leak in "check-vlan" test command.

Found by valgrind.

Signed-off-by: Ben Pfaff <blp@nicira.com>
bonding: Update bonding documentation in INTERNALS.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
tests: New m4 macro ON_EXIT to add a cleanup action.

Several of the tests start daemons and then need to make sure that the
daemons get killed when the test completes, even if it completes in the
middle due to an early failure.  Until now, they have been using manual
shell "trap" calls to do this.  This works well enough for simple cases,
but sometimes multiple macros start daemons in a single test, and then
each "trap" has to be carefully written to kill off the daemons for the
previously invoked macros.

This commit introduces a new macro ON_EXIT whose use is composable: each
call appends a new action to the ones already specified.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Kill off test-netflow daemon if test fails.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ofp-actions: Correct copyright statement.

This patch changes the name of Nicira from "Nicira Networks" which
is incorrect, to "Nicira, Inc." which is correct.

Signed-off-by: Ethan Jackson <ethan@nicira.com>
bond: Tag flows according to their hash bucket, not just their slave.

The bonding code is supposed to tag flows two ways:

    - According to the chosen bond slave, to make it easy to invalidate all
      of the flows assigned to a given slave.

    - According to the hash value for a flow, to make it easy to invalidate
      all of the flows that hash into the same bucket.

However, the code wasn't actually applying the hash-based tags.  This
meant that rebalancing didn't take effect immediately, and so after
rebalancing we could get log messages like this:

   inconsistency in subfacet (actions were: 5) (correct actions: 4)

specifying some flow that was moved by the rebalance.

This commit fixes the problem by applying the hash-based tags.

Bug #12847.
Reported-by: Pratap Reddy <preddy@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
dpif: Add 'used' argument to dpif_flow_stats_extract().

The following commit will need to use a value other than a literal
time_msec() in one case.  This commit is just preparation.

Factoring the time_msec() call out of the loop in
handle_flow_miss_without_facet() is a really minor optimization.  It isn't
the main point here.

Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif: Make sure one-packet flows have zero duration (again).

commit 6a0a5bbbc (ofproto-dpif: Make sure one-packet flows have zero
duration.) was supposed to fix failures in the "ofproto-dpif - NetFlow
flow expiration" test, but it didn't fix the whole problem.  That commit
eliminated one reason why a one-packet flow might be shown as having an
nonzero duration, but missed another.

The other reason was that the call to dpif_flow_stats_extract() could
obtain a time later than the time that a new facet was created.  (This
wasn't obvious because dpif_flow_stats_extract() obtained the time
internally instead of taking it from the caller.)  This commit fixes that
problem, by using the facet creation there too for the first packet in
a facet.

This problem has suddenly started showing up in a lot of builds.  I think
it's probably because of the recent change that makes x86-64 skip the timer
optimizations, so that the return value of time_msec() changes every 1 ms,
not just every 100 ms.

I've tested this by running the test in question in a loop for several
minutes, without any failures.

Signed-off-by: Ben Pfaff <blp@nicira.com>
stp: port_no counter is off by one

This counter was off by one, because port_num
should be less than STP_MAX_PORTS.

This caused an assert hit later in stp_get_port().

Issue: 13059
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>