From: Taha Sami <taha.sami@dreambigsemi.com>
To: "users@dpdk.org" <users@dpdk.org>,
"bingz@nvidia.com" <bingz@nvidia.com>,
"orika@nvidia.com" <orika@nvidia.com>,
"dsosnowski@nvidia.com" <dsosnowski@nvidia.com>
Cc: "asafp@nvidia.com" <asafp@nvidia.com>
Subject: connection tracking in mlx5 not working or displaying strange results
Date: Fri, 19 Apr 2024 13:09:30 +0000 [thread overview]
Message-ID: <BY5PR22MB198628034342226DB1474B06900D2@BY5PR22MB1986.namprd22.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 8695 bytes --]
Test Case 1: Working Fine
port stop all
flow configure 0 queues_number 9 queues_size 256 conn_tracks_number 4
flow pattern_template 0 create pattern_template_id 2 relaxed true ingress template tcp / end
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp / conntrack spec 1 / end
flow actions_template 0 create actions_template_id 1 template jump group 1 / end mask jump group 1 / end
flow actions_template 0 create actions_template_id 2 template jump group 5 / end mask jump group 5 / end
flow actions_template 0 create actions_template_id 4 template queue index 4 / end mask queue index 4 / end
flow template_table 0 create table_id 1 group 0 ingress rules_number 10 pattern_template 2 actions_template 1
flow template_table 0 create table_id 2 group 1 ingress rules_number 10 pattern_template 2 actions_template 2
flow template_table 0 create table_id 4 group 5 ingress rules_number 10 pattern_template 4 actions_template 4
port start all
set conntrack com peer 0 is_orig 1 enable 1 live 1 sack 1 cack 0 last_dir 1 liberal 0 state 1 max_ack_win 7 r_lim 5 last_win 510 last_seq 2 last_ack 1 last_end 2 last_index 0x2
set conntrack orig scale 7 fin 0 acked 1 unack_data 0 sent_end 2 reply_end 1 max_win 8192 max_ack 2
set conntrack rply scale 7 fin 0 acked 1 unack_data 0 sent_end 2 reply_end 1 max_win 8192 max_ack 1
flow queue 0 indirect_action 0 create action_id 9 ingress postpone no action conntrack / end
flow push 0 queue 0
flow pull 0 queue 0
flow queue 0 create 0 template_table 1 pattern_template 0 actions_template 0 postpone 0 pattern tcp / end actions jump group 1 / end
flow push 0 queue 0
flow pull 0 queue 0
flow queue 0 create 0 template_table 2 pattern_template 0 actions_template 0 postpone 0 pattern tcp / end actions indirect 9 / jump group 5 / end
flow push 0 queue 0
flow pull 0 queue 0
flow queue 0 create 0 template_table 4 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp / conntrack spec 1 / end actions queue index 4 / end
flow push 0 queue 0
flow pull 0 queue 0
Result:
It was observed that the packet was sent to the right queue when the correct packet was sent
Scapy Packet:
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=5555), iface="enp134s0f0",count=1) --->> redirect the packet to queue 4 for Flow rule 3
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=1234), iface="enp134s0f0",count=1) --->> redirect the packet to queue 6 for Flow rule 2
Test Case 2:
This test case has shown strange behavior when we keep everything similar to the above test case and just make changes in the pattern template and rule involving ct the match is not found and the packets are drop
Note: I have Tested this test on the same packets.
The changes We did our to find an exact match on tcp dst port
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp / conntrack spec 1 / end
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp dst is 5555 / conntrack spec 1 / end
For Flow Rule
flow queue 0 create 0 template_table 4 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp / conntrack spec 1 / end actions queue index 4 / end
flow queue 0 create 0 template_table 4 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp dst is 5555 / conntrack spec 1 / end actions queue index 4 / end
Result:
The packets were sent to queue 6 but not to queue for
Scapy Packet:
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=5555), iface="enp134s0f0",count=1) -- were not redirected to queue 4 for flow rule
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=1234), iface="enp134s0f0",count=1) --were redirected to queue 6 for Flow rule 2.
Test Case 3:
kept the same configuration for this test similar to test 1 except for some minor changes
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp / conntrack spec 1 / end
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp / conntrack is 1 / end
For Flow Rule:
flow queue 0 create 0 template_table 4 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp / conntrack spec 1 / end actions queue index 4 / end
flow queue 0 create 0 template_table 4 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp dst is 5555 / conntrack is 1 / end actions queue index 4 / end
Result:
The packets were sent to queue 6 but not to queue for
Scapy Packet:
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=5555), iface="enp134s0f0",count=1) -- were not redirected to queue 4 for flow rule
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=1234), iface="enp134s0f0",count=1) --were redirected to queue 6 for Flow rule 2.
Test Case 4:
In this test case, I have removed the ct object, The indirect action and configuration related to ct
NOTE: Please observe there are no ct object ,indirect action or connection tracking numbers in the following test
port stop all
flow configure 0 queues_number 9 queues_size 256
flow indirect_action 0 destroy action_id 0
flow indirect_action 0 destroy action_id 9
flow pattern_template 0 create pattern_template_id 2 relaxed true ingress template tcp / end
flow pattern_template 0 create pattern_template_id 3 relaxed true ingress template eth / ipv4 / tcp dst is 1234 / end
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp / conntrack spec 65535 / end
flow actions_template 0 create actions_template_id 1 template jump group 1 / end mask jump group 1 / end
flow actions_template 0 create actions_template_id 2 template jump group 5 / end mask jump group 5 / end
flow actions_template 0 create actions_template_id 3 template queue index 6 / end mask queue index 6 / end
flow actions_template 0 create actions_template_id 4 template queue index 4 / end mask queue index 4 / end
flow template_table 0 create table_id 1 group 0 ingress rules_number 10 pattern_template 2 actions_template 1
flow template_table 0 create table_id 2 group 1 ingress rules_number 10 pattern_template 2 actions_template 2
flow template_table 0 create table_id 3 group 5 ingress rules_number 10 pattern_template 3 actions_template 3
flow template_table 0 create table_id 4 group 5 ingress rules_number 10 pattern_template 4 actions_template 4
port start all
flow queue 0 create 0 template_table 1 pattern_template 0 actions_template 0 postpone 0 pattern tcp / end actions jump group 1 / end
flow push 0 queue 0
flow pull 0 queue 0
flow queue 0 create 0 template_table 2 pattern_template 0 actions_template 0 postpone 0 pattern tcp / end actions jump group 5 / end
flow push 0 queue 0
flow pull 0 queue 0
flow queue 0 create 0 template_table 3 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp dst is 1234 / end actions queue index 6 / end
flow push 0 queue 0
flow pull 0 queue 0
flow queue 0 create 0 template_table 4 pattern_template 0 actions_template 0 postpone 0 pattern eth / ipv4 / tcp / conntrack spec 65535 / end actions queue index 4 / end
flow push 0 queue 0
flow pull 0 queue 0
set verbose 3
start
Result:
The packets were sent to Queue 6 and Queue 4.
This shouldn't be the case since no ct object was created in the rule and their was no indirect action.
Scapy Packet:
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=5555), iface="enp134s0f0",count=1) -- were redirected to queue 4 for flow rule
sendp( Ether(dst="B8:CE:F6:D2:CD:22",src="aa:bb:cc:dd:ee:ff")/IP()/TCP(dport=1234), iface="enp134s0f0",count=1) --were redirected to queue 6 for Flow rule 2.
Summary:
*
Test case 1 worked as it was intended and packets were redirected to the desired queues
*
Test Cases 2 and 3 did not work as it was intended when matching on the exact tcp dst port and when the connection tracking keyword is was used.
*
Test case 4 sent the packet to their desired queues but they shouldn't have because no ct context was created and no indirection action was created
Regards,
Taha
flow pattern_template 0 create pattern_template_id 4 relaxed true ingress template eth / ipv4 / tcp / conntrack spec 1 / end
Test Case 1:
[-- Attachment #2: Type: text/html, Size: 40440 bytes --]
next reply other threads:[~2024-04-19 14:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 13:09 Taha Sami [this message]
2024-04-26 18:57 ` Dariusz Sosnowski
2024-04-30 13:10 ` Taha Sami
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=BY5PR22MB198628034342226DB1474B06900D2@BY5PR22MB1986.namprd22.prod.outlook.com \
--to=taha.sami@dreambigsemi.com \
--cc=asafp@nvidia.com \
--cc=bingz@nvidia.com \
--cc=dsosnowski@nvidia.com \
--cc=orika@nvidia.com \
--cc=users@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).