RTE_FLOW not matching UDP ports in head fragments?

RTE_FLOW not matching UDP ports in head fragments?

[Tony Hart]

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

RE: RTE_FLOW not matching UDP ports in head fragments?

[Dariusz Sosnowski]

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

Re: 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@nvidia.com> wrote:
>
> 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



-- 
tony