On 5 March 2014 10:50, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Mar 05, 2014 at 10:47:33AM -0800, Joe Stringer wrote: > > On 4 March 2014 14:49, Ben Pfaff <b...@nicira.com> wrote: > > > 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? > > > > > > > I think it's worth exploring, but I'd like to explore it independently of > > this patch. It's not entirely obvious to me right now that contention on > > these hmaps is a problem. That is to say, currently we spend far more > time > > in action translation for pushing stats than we do contending on > > revalidator hmaps. Another patchset I plan to post RFC this week will > begin > > to address this area, and I have some ideas about sharing these hmaps > with > > handler threads; that looks like a more logical time to visit this. > > OK. > > It took me some studying to figure out what was going on, so let me > suggest a simple way to make it clearer: move the ukeys hmaps, and the > associated mutexes, out of the revalidator-specific structs into the > parent udpif. Then at least it doesn't look at first glance like the > hmaps are basically owned by the threads. > > What do you think of that idea? >
I'm open to it. How do you suggest that we determine which revalidator does garbage collection for which hmap? The simplest option I can see from an implementation point of view, is to initialise a pointer inside the revalidator when we construct them. Revalidators would use udpif->ukeys[idx] when dumping flows, then use revalidator->ukeys to handle garbage collection.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
