Hi Tony, > -----Original Message----- > From: Tony Hart <[email protected]> > Sent: Thursday, March 21, 2024 18:24 > To: [email protected] > 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
