[ovs-dev] [RFC 05/14] udpif: Separate ukey maps from revalidators.

Ben Pfaff blp at nicira.com
Fri Aug 22 19:59:07 UTC 2014

On Thu, Aug 21, 2014 at 05:42:00PM +1200, Joe Stringer wrote:
> An upcoming patch will change the access patterns for ukey maps to
> increase the number of writers, and shift write-access from revalidator
> threads to upcall handler threads. As such, it no longer makes sense to
> tie these maps to revalidators in a 1:1 relationship.
> This patch separates the ukey maps from the revalidators, and increases
> the number of maps used to store ukeys, to reduce contention.
> Signed-off-by: Joe Stringer <joestringer at nicira.com>

n_umaps is now a hard-coded constant, but a lot of the code assumes
that it can vary.  It would be very slightly simpler to actually use a
macro or enum to define the fixed size instead of a variable.  It
would also allow better code generation in ukey_lookup() and
ukey_acquire() since hash % 128 is just hash & 0x7f, which ought to be
much cheaper than a general-purpose modulo operation.  I suggest
making the change for that latter reason.

upcall_unixctl_show() assert-fails if n_revalidators > 64, but nothing
in the code, that I see, limits the number of revalidators to that
number.  We should limit the revalidators or just dynamically allocate
'elements'.  Actually, here's a simpler solution: get rid of
'elements' and have the loop that read it construct each element as it
goes using a loop like the one in revalidator_sweep__().

Acked-by: Ben Pfaff <blp at nicira.com>

More information about the dev mailing list