ovs-thread: Add new support for thread-specific data.

A couple of times I've wanted to create a dynamic data structure that has
thread-specific data, but I've not been able to do that because
PTHREAD_KEYS_MAX is so low (POSIX says at least 128, glibc is only a little
bigger at 1024).  This commit introduces a new form of thread-specific data
that supports a large number of items.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
fat-rwlock: New big but fast synchronization primitive.

This implements a reader-writer lock that uses a lot of memory (128 to 192
bytes per thread that takes the lock) but avoids cache line bouncing when
taking the read side.  Thus, a fat_rwlock is a good choice for rwlocks
taken frequently by readers.

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
classifier: Use fat_rwlock instead of ovs_rwlock.

Jarno Rajahalme reported up to 40% performance gain on netperf TCP_CRR with
an earlier version of this patch in combination with a kernel NUMA patch,
together with a reduction in variance:
    http://openvswitch.org/pipermail/dev/2014-January/035867.html

Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
fat-rwlock: Don't forget to destroy a mutex

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-xlate: Fix a whitespace error.

No functional changes.

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
bridge: Update a comment

This looks like a leftover of commit 2a73b1d73d.
("bridge: Reconfigure in single pass.")

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofproto-dpif-xlate: Avoid recursive acquisition of xlate_rwlock.

Currently xlate_rwlock is recursively acquired.
(xlate_send_packet -> ofproto_dpif_execute_actions -> xlate_actions)
Due to writer-preference in rwlock implementations, this causes
deadlock if another thread tries to acquire the lock exclusively
behind us.

This change avoids the problem by making xlate_send_packet drop
the lock before calling ofproto_dpif_execute_actions.  This is the
simplest fix but opens a race window against port reconfigurations.
Given the way xlate_send_packet is currently used, the race does not
seem a big problem.  An alternative would be passing down the
"xlate_rwlock is held" info to ofproto_dpif_execute_actions.

Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
datapath: Pad OVS_PACKET_ATTR_PACKET if linear copy was performed

While the zerocopy method is correctly omitted if user space
does not support unaligned Netlink messages. The attribute is
still not padded correctly as skb_zerocopy() will not ensure
padding and the attribute size is no longer pre calculated
though nla_reserve() which ensured padding previously.

This patch applies appropriate padding if a linear data copy
was performed in skb_zerocopy().

Signed-off-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
ofproto-dpif: Add more lock annotations.

This annotation would have caught the bug fixed by commit 491a67a0005347130
(ofproto-dpif-xlate: Avoid recursive acquisition of xlate_rwlock.).

Signed-off-by: Ben Pfaff <blp@nicira.com>
CC: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
ofproto-dpif-monitor: Change global rwlock into mutex.

Nothing ever took monitor_rwlock's read lock, so it might as well be a
mutex.

Signed-off-by: Ben Pfaff <blp@nicira.com>