This function doesn't need to be exported in the public OVS headers, and
it had an inconsistent name compared to uuid_equals(). Rename and move.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This commit tries to simplify and further clarify the test cases
in test-hash.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This commit makes check_word_hash() run to finish even when there
is a failure during the run. The test will still fail due to the
output check in AT_CHECK. And developers can benefit from having
all failed hashes instead of only the first one.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This commit adds a new test for hash_bytes128() using single 128-bit
word. The test shows that there is no collision in all 19 consecutive
bits checks, which indicates the hash function is good.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
The original test fails on big-endian system due to the hash function
performing not as well when input is uint32_t. In reality, users should
only use hash_bytes128() to hash words larger than 128 bits (e.g. struct
flow). Besides, we do check the 1-bit set case for 16 128-bit words in
following test case. Therefore, the cleanest way to fix the failure
in big-endian system seems to be just removing the check_word_hash()
test for hash_bytes128_cb.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This commit refines the check_256byte_hash() function by moving
some checks to outer loop.
Signed-off-by: Alex Wang <alexw@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The test comment mentions that we will test the no 1-bits set case.
So, this commit makes sure that it is tested.
Signed-off-by: Alex Wang <alexw@nicira.com>
---
PATCH->V2:
- explain why calling set_bit128 with i or j == n_bits is okay.
./configure accepts --enable-ndebug option. Make ovs_assert() honor
it, and make sure all test programs disable it.
The order of include files in test programs is also made uniform:
1. #include <config.h>
2. #undef NDEBUG
3. Include file of the test subject (to make sure it itself has
sufficient include directives).
4. System includes in alphapetical order.
5. OVS includes in aplhapetical order.
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This just makes it a bit easier for someone coming in fresh to do some
searches and figure out what the description means.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Use CRC32 intrinsics for hash computations when building for
X86_64 with SSE4_2.
Add a new hash_words64() and change hash_words() to be inlined when
'n_words' is a compile-time constant.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Improve link speed by linking 29 test programs into ovstest.
On my machine, running the following command against a fully
built tree:
$ touch lib/random.c; time make
Improve the overall build time from 7 seconds to 3.5 seconds.
Signed-off-by: Andy Zhou <azhou@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
murmurhash is faster than Jenkins and slightly higher quality, so switch to
it for hashing words.
The best timings I got for hashing for data lengths of the following
numbers of 32-bit words, in seconds per 1,000,000,000 hashes, were:
words murmurhash Jenkins hash
----- ---------- ------------
1 8.4 10.4
2 10.3 10.3
3 11.2 10.7
4 12.6 18.0
5 13.9 18.3
6 15.2 18.7
In other words, murmurhash outperforms Jenkins for all input lengths other
than exactly 3 32-bit words (12 bytes). (It's understandable that Jenkins
would have a best case at 12 bytes, because Jenkins works in 12-byte
chunks.) Even in the case where Jenkins is faster, it's only by 5%. On
average within this data set, murmurhash is 15% faster, and for 4-word
input it is 30% faster.
We retain Jenkins for flow_hash_symmetric_l4() and flow_hash_fields(),
which are cases where the hash value is exposed externally.
This commit appears to improve "ovs-benchmark rate" results slightly by
a few hundred connections per second (under 1%), when used with an NVP
controller.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
Murmurhash is generally superior to the Jenkins lookup3 hash according to
the available figures. Perhaps we should generally replace our current
hashes by murmurhash.
For now, I'm introducing a parallel implementation to allow it to be used
in cases where an incremental one-word-at-a-time hash is desirable. The
first user will be added in an upcoming commit.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>