> 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?
Jarno
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
