[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