RTE_FLOW not matching UDP ports in head fragments?

[Tony Hart]

Hi Dariusz,
Thanks for looking into this.

On Tue, Mar 26, 2024 at 8:57 AM Dariusz Sosnowski <dsosnowski at nvidia.com> wrote:
>
> Hi Tony,
>
> > -----Original Message-----
> > From: Tony Hart <tony.hart at domainhart.com>
> > Sent: Thursday, March 21, 2024 18:24
> > To: users at 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



-- 
tony