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>