On Wed, Mar 05, 2014 at 11:03:24AM -0800, Joe Stringer wrote: > 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.
That's fine with me. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
