> On May 29, 2015, at 5:23 PM, Ben Pfaff <b...@nicira.com> wrote:
>
> + * Tentative Modifications
> + * =======================
> + *
> + * When a new rule is added to a classifier, it can optionally be
> "invisible".
> + * That means that lookups won't find the rule, although iterations through
> + * the classifier will still see it.
> + *
> + * Similarly, deletions from a classifier can be "tentative", by setting
> + * 'to_be_removed' to true within the rule. A rule that is tentatively
> deleted
> + * will not appear in iterations, although it will still be found by lookups.
> + *
> + * Classifiers can hold duplicate rules (rules with the same match criteria
> and
> + * priority) when tentative modifications are involved: one (or more)
> identical
> + * tentatively deleted rules can coexist in a classifier with at most one
> + * identical invisible rule.
> + *
> + * The classifier supports tentative modifications for two reasons:
> + *
> + * 1. Performance: Adding (or deleting) a rule can, in pathological
> cases,
> + * have a cost proportional to the number of rules already in the
> + * classifier. When multiple rules are being added (or deleted) in
> one
> + * go, though, this cost can be paid just once, not once per addition
> + * (or deletion), as long as it is OK for any new rules to be
> invisible
> + * until the batch change is complete.
> + *
> + * 2. Staging additions and deletions: Invisibility allows a rule to be
> + * added tentatively, to possibly be modified or removed before it
> + * becomes visible. Tentatively deletion allows a rule to be
> scheduled
> + * for deletion before it is certain that the deletion is desirable.
> + *
> + * To use deferred publication, first call classifier_defer(). Then, modify
> + * the classifier via additions and deletions. Call cls_rule_make_visible()
> on
> + * each new rule at an appropriate time. Finally, call classifier_publish().
> + *
> + *
Thanks, I added these changes and this incremental clarification:
struct cls_rule {
struct rculist node; /* In struct cls_subtable 'rules_list'. */
int priority; /* Larger numbers are higher priorities. */
- bool to_be_removed; /* Rule will be deleted. */
+ bool to_be_removed; /* Rule will be deleted.
+ * This is the only field that may be
+ * modified after the rule has been added to
+ * a classifier. Modifications are to be
+ * done only under same locking as all other
+ * classifier modifications. This field may
+ * not be examined by lookups. */
struct cls_match *cls_match; /* NULL if not in a classifier. */
struct minimatch match; /* Matching rule. */
};
After patch 17/19 all changes to ‘to_be_removed’ are done in the classifier
functions. There are two asserts and one other use for checking the status of
‘to_be_removed’, I’ll add a getter for it in the v2 of patch 17/19.
Thanks,
Jarno
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
