[ovs-dev] [PATCH v2 05/19] classifier: Support duplicate rules.

Jarno Rajahalme jrajahalme at nicira.com
Mon Jun 1 20:41:35 UTC 2015


> On May 29, 2015, at 5:23 PM, Ben Pfaff <blp at 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




More information about the dev mailing list