On Thu, Nov 13, 2014 at 11:56:14AM -0800, Jarno Rajahalme wrote:
> Previously, accurate iteration required writers to be excluded during
> iteration. This patch adds an rculist to struct cls_subtable, and a
> corresponding list node to struct cls_rule, which makes iteration more
> straightforward, and allows the iterators to remain ignorant of the
> internals of the cls_match. This new list allows iteration of rules
> in the classifier by traversing the RCU-friendly subtables vector, and
> the rculist of rules in each subtable.
>
> Classifier modifications may be performed concurrently, but whether or
> not the concurrent iterator sees those changes depends on the timing
> of change. More specifically, an concurrent iterator:
>
> - May or may not see a rule that is being inserted or removed.
> - Will see either the new or the old version of a rule that is replaced.
> - Will see all the other rules (that are not being modified).
>
> Finally, The subtable's rculist also allows to make
> classifier_rule_overlaps() lockless, which this patch also does.
>
> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com>
Thanks, this is nice!
> /* A set of rules that all have the same fields wildcarded. */
> struct cls_subtable {
> - /* The fields are only used by writers and iterators. */
> - struct cmap_node cmap_node; /* Within struct classifier 'subtables_map'.
> */
> -
> - /* The fields are only used by writers. */
> + /* These fields are only used by writers. */
> + struct cmap_node cmap_node OVS_GUARDED; /* Within struct classifier's
> + * 'subtables_map'. */
If cmap_node is only used by writers (which have to have mutual
exclusion), then it's questionable whether a cmap is the right data
structure, since the main advantage of a cmap is to allow search and
iterate to operate concurrently with modification. But it looks like
classifier_find_rule_exactly(), which is not a write operation, also
uses the cmap_node.
Otherwise:
Acked-by: Ben Pfaff <b...@nicira.com>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
