[dpdk-dev] [Bug 79] ACL doesn't match a rule with a first `TYPE_MASK` field with low mask when there's a large number of rules

[bugzilla at dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=79

            Bug ID: 79
           Summary: ACL doesn't match a rule with a first `TYPE_MASK`
                    field with low mask when there's a large number of
                    rules
           Product: DPDK
           Version: 18.05
          Hardware: All
                OS: Linux
            Status: CONFIRMED
          Severity: normal
          Priority: Normal
         Component: other
          Assignee: dev at dpdk.org
          Reporter: t-pehous at microsoft.com
  Target Milestone: ---

ACL doesn't match a rule with `TYPE_MASK` field that has low mask when there's
a large number of rules

ACL doesn't match a catch-all rule (0 bit mask for 'TYPE_MASK', max ranges for
'TYPE_RANGE') when there's a large number (~1000) of other rules. The lower the
mask lenght is for the rule's first `TYPE_MASK` field, the smaller the overall
number of rules must be for the matching to work reliably. 

Specifically I created a small benchmark app based on the fwdl3-acl sample that
generates random ipv4 rules and relevant ipv4 packet data and then matches the
packets to the rules. In addition to random rules it also adds a catch-all rule
in the end with a prioroty 0 that should always match. When there's a large
number of generated rules, however, it doesn't and some packets end up not
being matched by any rules.

The catch-all rule works great with the exception of source ipv4 address mask.
When the mask is lower than 6 and overall number of rules (i.e. the random
ones) is around 10 000, the (catch-almost-all) rule doesn't match all packets
it should. When the mask is lower than 4, the max number for the matching to
work reliably is around 800. When the mask is zero -> i.e. when it's truly a
catch-all rule it works reliably with only tens of other rules.

No other fields of the rule seem to have an impact, nor have I seen an instance
when a rule would match data it shouldn't've.

The linked code shows rule definition, rule generation, and packet generation.
For simplicity it's a modified version that only creates one packet that should
_always_ be matched by the catch_all rule no matter what it's mask is. It,
however, is not as also linked logs show.

CODE: https://gist.github.com/petrroll/5a462d65253b18b5e78c2c7efba2cb8c

-- 
You are receiving this mail because:
You are the assignee for the bug.