On Wed, Aug 26, 2015 at 01:59:39PM -0700, Jarno Rajahalme wrote:
>
> > On Aug 26, 2015, at 1:41 PM, Ben Pfaff <b...@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 <b...@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!
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
