lib/match: Do not format undefined fields.

Add function flow_wildcards_init_for_packet() that can be used to set
sensible wildcards when megaflows are disabled.  Before this, we set
all the mask bits to ones, which caused printing tunnel, mpls, and/or
transport port fields even for packets for which it makes no sense.

This has the side effect of generating different megaflow masks for
different packet types, so there will be more than one kind of mask in
the datapath classifier.  This should not make practical difference,
as megaflows should not be disabled when performance is important.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/meta-flow: Index correct MPLS lse in mf_is_all_wild().

Should index the first lse for all parts of the lse (label, TC, BOS).

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

Previously we masked labels not present in the incoming packet.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/cmap: Return number of nodes from functions modifying the cmap.

We already update the count field as the last step of these functions,
so returning the current count is very cheap.  Callers that care about
the count become a bit more efficient, as they avoid extra
non-inlineable function call.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
tests/test-cmap: Balance benchmarks between cmap and hmap.

The test cases have been carefully crafted so that we do the same
amount of "overhead" operations in each case.  Earlier, with no
mutations, the number of random number generations was different for
hmap and cmap test cases.  hmap test was also missing an ignore() call.
Now the numbers look like this:

$ tests/ovstest test-cmap benchmark 2000000 8 0
Benchmarking with n=2000000, 8 threads, 0.00% mutations:
cmap insert:    597 ms
cmap iterate:    65 ms
cmap search:    299 ms
cmap destroy:   251 ms

hmap insert:    243 ms
hmap iterate:   201 ms
hmap search:    299 ms
hmap destroy:   202 ms

So it seems search on cmap can be as fast as on hmap in the
single-threaded case.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/cmap: More efficient cmap_find().

    These makes cmap_find 10% faster on GCC 4.7 (-O2 -g).

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/cmap: Use non-atomic access to hash.

We use the 'counter' as a "lock" providing acquire-release
semantics.  Therefore we can use normal, non-atomic access to the
memory accesses between the atomic accesses to 'counter'.  The
cmap_node.next needs to be RCU, so that can not be changed.

For the writer this is straightforward, as we first acquire-read the
counter and after all the changes we release-store the counter.  For
the reader this is a bit more complex, as we need to make sure the
last counter read is not reordered with the preceding read operations
on the bucket contents.

Also rearrange code to benefit from the fact that hash values are
unique in any bucket.

This patch seems to make cmap_insert() a bit faster.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/cmap: split up cmap_find().

This makes the following patch easier and cleans up the code.

Explicit "inline" keywords seem necessary to prevent performance
regression on cmap_find() with GCC 4.7 -O2.

Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
lib/cmap: cmap_find_batch().

Batching the cmap find improves the memory behavior with large cmaps
and can make searches twice as fast:

$ tests/ovstest test-cmap benchmark 2000000 8 0.1 16
Benchmarking with n=2000000, 8 threads, 0.10% mutations, batch size 16:
cmap insert:    533 ms
cmap iterate:    57 ms
batch search:   146 ms
cmap destroy:   233 ms

cmap insert:    552 ms
cmap iterate:    56 ms
cmap search:    299 ms
cmap destroy:   229 ms

hmap insert:    222 ms
hmap iterate:   198 ms
hmap search:   2061 ms
hmap destroy:   209 ms

Batch size 1 has small performance penalty, but all other batch sizes
are faster than non-batched cmap_find().  The batch size 16 was
experimentally found better than 8 or 32, so now
classifier_lookup_miniflow_batch() performs the cmap find operations
in batches of 16.

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