From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/other Bug 1417] RTE_FLOW not matching UDP ports in head fragments
Date: Thu, 18 Apr 2024 15:28:25 +0000 [thread overview]
Message-ID: <bug-1417-3@http.bugs.dpdk.org/> (raw)
[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4723 bytes --]
reply other threads:[~2024-04-18 15:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-1417-3@http.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.