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 <joestrin...@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 <b...@nicira.com> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
