Thanks, I tidied up the comments, added threadsafety annotations for xcache
and pushed.
On 24 April 2014 06:38, Ben Pfaff <b...@nicira.com> wrote:
> On Tue, Apr 22, 2014 at 04:54:24PM +1200, 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>
>
> Here in the definition of struct udpif, I would mention that there are
> n_revalidators member of 'ukeys'. Otherwise the casual reader might
> guess that there was only one:
> > + /* During the flow dump phase, revalidators insert into these with
> a random
> > + * distribution. During the garbage collection phase, each
> revalidator
> > + * takes care of garbage collecting one of these hmaps. */
> > + struct {
> > + struct ovs_mutex mutex; /* Guards the following. */
> > + struct hmap hmap OVS_GUARDED; /* Datapath flow keys. */
> > + } *ukeys;
>
> In the definition of struct udpif_key, the synchronization of most of
> the members is pretty clear, except for 'xcache'.
>
> Acked-by: Ben Pfaff <b...@nicira.com>
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
