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

            Bug ID: 1417
           Summary: RTE_FLOW not matching UDP ports in head fragments
           Product: DPDK
           Version: 24.03
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: other
          Assignee: dev@dpdk.org
          Reporter: tony.hart@domainhart.com
  Target Milestone: ---

Using RTE_FLOW (with the asynchronous API) to match UDP packets coming
from a particular port and destination address.  This is on a
Nvidia/Mellanox CX6.  This works great whilst the packets are not
fragmented, however, when the packet is fragmented it does not match.
I was expecting that it would still match the head fragment since it
still contains the UDP header and hence the port (obviously I'm not
expecting it to match the tail fragment).

Is this intended behavior (looking at the rte_mbuf_ptype code it
suggests that it is)?

In the script below I see the count for the first entry in group 3
increment for the non-fragmented case but when the length of the
(otherwise) same packet is one byte longer than the MTIU, the counter
of the second group 3 entry is incremented instead.

Thanks for any insights,
Tony

FYI this is using the v24.03-rc2 dpdk release.

port stop all
flow configure 0 queues_number 1 queues_size 64 counters_number 1000
port start all

# PATTERN TEMPLATES
flow pattern_template 0 create pattern_template_id 0 ingress template end
flow pattern_template 0 create pattern_template_id 1 ingress template
eth / ipv4 dst mask 0xffffffff / udp src mask 0xffff / end

# ACTION TEMPLATES
flow actions_template 0 create actions_template_id 0 template jump /
end mask jump / end
flow actions_template 0 create actions_template_id 1 template count /
drop / end mask count / drop / end

# TEMPLATE TABLES
flow template_table 0 create table_id 0 group 0 priority 0 ingress
rules_number 1 pattern_template 0 actions_template 0
flow template_table 0 create table_id 8 group 3 priority 1 ingress
rules_number 100 pattern_template 1 actions_template 1
flow template_table 0 create table_id 9 group 3 priority 99 ingress
rules_number 1 pattern_template 0 actions_template 1

# GROUP 0
flow queue 0 create 0 template_table 0 pattern_template 0
actions_template 0 postpone no pattern end actions jump group 3 / end

# GROUP 3:
flow queue 0 create 0 template_table 8 pattern_template 0
actions_template 0 postpone no pattern eth / ipv4 dst spec 2.2.3.1 /
udp src spec 389 / end actions count / drop / end
flow queue 0 create 0 template_table 9 pattern_template 0
actions_template 0 postpone no pattern end actions count / drop / end

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