On Fri, Feb 28, 2014 at 01:42:14PM -0800, Joe Stringer wrote: > From: Ethan Jackson <et...@nicira.com> > > Previously, we had a separate flow_dumper thread that fetched flows from > the datapath to distribute to revalidator threads. This patch takes the > logic for dumping and pushes it into the revalidator threads, resulting > in simpler code with similar performance to the current code. > > One thread, the "leader", is responsible for beginning and ending each > flow dump, maintaining the flow_limit, and checking whether the > revalidator threads need to exit. All revalidator threads dump, > revalidate, delete datapath flows and garbage collect ukeys. > > Co-authored-by: Joe Stringer <joestrin...@nicira.com> > Signed-off-by: Joe Stringer <joestrin...@nicira.com>
After studying the code for a while, I think I see something odd. Each 'ukeys' hmap is associated with a revalidator thread, but the hmaps have barely any relationship with their owning thread. Except during the "sweep", it's not more likely, for example, that a thread will access a ukey in its hmap than in any other hmap. If we were to maintain the ukeys hmaps separately, then we wouldn't have to have the same number of hmaps as threads. That seems, off-hand, like a good thing, since the degree of parallelism depends on the number of hmaps as well as on the number of threads: increasing the number of hmaps, while holding the number of threads constant, will still help somewhat. What do you think? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
