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

Ben Pfaff blp at nicira.com
Wed Aug 26 21:39:52 UTC 2015


On Wed, Aug 26, 2015 at 01:59:39PM -0700, Jarno Rajahalme wrote:
> 
> > 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?

I doubt tunnel metadata matches are significant.

OK, given your confidence (and the significant performance benefit),
I'll reserve my doubts and review this in detail.  Thanks!



More information about the dev mailing list