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

Ben Pfaff blp at nicira.com
Wed Aug 26 20:41:42 UTC 2015

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.

More information about the dev mailing list