> 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. Jarno >> Removing the partitioning feature makes classifier lookups roughly 20% >> faster when a wildcard mask is not needed, and roughly 10% faster when >> a wildcard mask is needed, as tested with the test-classifier >> benchmark with one lookup thread. >> >> Found by profiling with 'perf'. >> >> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
