[ovs-dev] [PATCH v5 4/6] classifier: Retire partitions.

Jarno Rajahalme jrajahalme at nicira.com
Wed Aug 26 20:59:39 UTC 2015

> On Aug 26, 2015, at 1:41 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Wed, Aug 26, 2015 at 01:31:25PM -0700, Jarno Rajahalme wrote:
>>> On Aug 26, 2015, at 10:15 AM, Ben Pfaff <blp at nicira.com> wrote:
>>> On Fri, Aug 21, 2015 at 03:25:21PM -0700, Jarno Rajahalme wrote:
>>>> Classifier partitions allowed skipping subtables when if was known
>>>> from the flow's metadata field that the subtable cannot possibly
>>>> match.  This functionality was later implemented in a more general
>>>> fashion by staged lookup, where the first stage also covers the
>>>> metadata field, among the rest of the non-packet fields in the struct
>>>> flow.  While in theory skipping a subtable on the basis of the
>>>> metadata field alone could produce more effective wildcards, on the
>>>> basis of our testsuite coverage it does not seem to be the case, as
>>>> removing the partitioning feature did not result in any test failures.
>>> I don't understand this part of the rationale.  Why would removing a
>>> classifier optimization cause test failures?
>> If we can skip a subtable based on the partition, we do not need to
>> add any bits to the flow wildcards, as the only field we examined was
>> the ‘metadata’ field, which has no datapath representation. Now, if we
>> instead go to the metadata stage and find the subtable cannot contain
>> a match (at least the metadata field value of the flow would be
>> different from any of the rules in the classifier, otherwise we could
>> not have skipped this subtable with partitions), we need to unwildcard
>> all the bits in any of the metadata covered by the metadata
>> stage. These could include in_port, skb_priority, tunnel metadata,
>> etc. In this case we could unwildcard more bits than with partition
>> check alone. This could cause a test case failure, as the wildcard
>> mask could be different.
> Oh, a testcase failure not based on the correctness of the
> classification algorithm but based on a change in the wildcard mask
> generated by the algorithm.  I see.
> I doubt that the testsuite ever really exercised this optimization, but
> it's intended for OVN (and before it, NVP) which uses the OpenFlow
> metadata field to partition each OpenFlow table according to the logical
> datapath.  The idea is that, if logical switch A has complicated flows
> and exercises special features, and logical switch B does not, then
> packets from B should not suffer from excessive matching
> ("unwildcarding").  Do you think that partitioning is not actually
> necessary to achieve that?  It's hard for me to judge that on the basis
> of the testsuite that doesn't really test it, but if you think that it
> is the case then I'll accept your judgment.

If the complicated flows deal with actual packet fields (like ACLs would, for example) then the staged lookup failure on metadata stage (non-matching ‘metadata’ field) will take care of the partitioning (skipping the rest of the subtable). The only concern is the other metadata in the metadata stage. I do not know how likely it is that the subtables of interest would match on e.g. tunnel metadata that would otherwise not get unwildcarded?


More information about the dev mailing list