RE: RTE_FLOW not matching UDP ports in head fragments?

[Dariusz Sosnowski <dsosnowski@nvidia.com>]

Hi Tony,

> -----Original Message-----
> From: Tony Hart <tony.hart@domainhart.com>
> Sent: Thursday, March 21, 2024 18:24
> To: users@dpdk.org
> Subject: RTE_FLOW not matching UDP ports in head fragments?
> 
> 
> 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

In this case the first fragment should be matched against the flow rule with ETH / IPV4 / UDP.
I was able to reproduce the issue internally using the commands you provided.
We'll investigate it and let you know.

Best regards,
Dariusz Sosnowski