DPDK rte_flow rules RSS support for more NICs - v4 #12490
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 4 commits
January 27, 2025 18:43
Move and adjust the base of RSS configuration from util-dpdk-i40e.c to a new file that can be later utilized by other cards. RSS configuration can be configured via rte_flow rules. This is useful for possible future features such as specific header offload (vxlan, nvgre) also implemented via rte_flow rules, as rte_flow rules can be chained via groups and priorities. i40e uses multiple different rte_flow rules to setup RSS. At first, function DeviceSetRSSFlowQueues() is used to setup rx queues. This rule matches all types of traffic, so the equivalent to dpdk-testpmd pattern would be "pattern end" This rule can not contain hash types (ipv4, ipv6 etc.) nor hash key. The hash function used here is RTE_ETH_HASH_FUNCTION_DEFAULT. The syntax in dpdk-testpmd for this rule with attributes: port index == 0 used rx queue indices == 0 1 2 3 is as follows: "flow create 0 ingress pattern end actions rss queues 0 1 2 3 end func default / end" The other rules configured by i40eDeviceSetRSSFlowIPv4() and i40eDeviceSetRSSFlowIPv6() match specific type of traffic by l4 protocol (none, TCP, UDP, SCTP). For example, pattern to match l3 ipv4 with l4 tcp traffic in dpdk-testpmd syntax would be equivalent of "pattern eth / ipv4 / tcp / end". These rules can not have rx queues configured, but have hash types (l3 src and dst address). This means that the traffic distribution is affected only by l3 addresses, independent of the l4 specifics. Also these pattern matching rules have symmetric 6d5a hash key configured. The length of the key is dependent on DPDK version. The hash function (either RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ or RTE_ETH_HASH_FUNCTION_TOEPLITZ, depending on DPKD version) used in these rules hashes symmetricaly due to the symmetric hash key. The syntax in dpdk-testpmd for rule to match ipv4-tcp traffic with attributes: port index == 0 <hash_key> == 52 bytes long 6d5a symmetric hash key is as follows: "flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss types ipv4-tcp l3-src-only l3-dst-only end queues end key <hash_key> key_len 52 func toeplitz / end" (queues need to be set to NULL) Ticket: 7337
ixgbe driver requires different configuration of RSS rte_flow rule than i40e, with just one generic rule matching all traffic. The generic rule configured by DeviceCreateRSSFlowGeneric() has pattern equivalent to "pattern eth / end" in dpdk-testpmd syntax. The rule must have rx queues configured. The rule hashes traffic to different queues based on ipv4 and ipv6 hash types (ipv4 src dst / ipv6 src dst). The hash key is 40 bytes long symmetric hash key. ixgbe does not support any other hash function than RTE_ETH_HASH_FUNCTION_DEFAULT. The syntax in dpdk-testpmd for this rule with attributes: port index == 0 used rx queue indices == 0 1 2 3 <hash_key> == 6d5a symmetric hash key is as follows: "flow create 0 ingress pattern eth / end actions rss types ipv4 ipv6 end queues 0 1 2 3 end key <hash_key> key_len 40 func default / end" Ticket: 7337
ice driver requires 2 rte_flow rules for matching and
redistributing incoming traffic with RSS.
The rules set up by iceDeviceSetRSSFlowIPv4() and
iceDeviceSetRSSFlowIPv6() are different only in the pattern
("pattern eth / ipv4 / end" or "pattern eth / ipv6 / end"
in dpdk-testpmd syntax) and in the hash type (ipv4 src dst / ipv6 src
dst). ice will match all ipv4 or ipv6 traffic independently of
following l4 protocol. The rules can not have queues configured,
implicitly they will use all queues available.
The hash function is set to RTE_ETH_HASH_FUNCTION_TOEPLITZ.
The hash key can not be set.
The syntax in dpdk-testpmd for rule to match all ipv4 traffic
with attributes:
port index == 0
is as follows:
"flow create 0 ingress pattern eth / ipv4 / end actions rss types ipv4
end queues end func toeplitz / end"
(queues need to be set to NULL)
Ticket: 7337
The configuration of this rule is the same as for ixgbe driver except the hash function is not RTE_ETH_HASH_FUNCTION_DEFAULT but RTE_ETH_HASH_FUNCTION_TOEPLITZ. The syntax in dpdk-testpmd for this rule with attributes: port index == 0 used rx queue indices == 0 1 2 3 <hash_key> == 6d5a symmetric hash key is as follows: "flow create 0 ingress pattern eth / end actions rss types ipv4 ipv6 end queues 0 1 2 3 end key <hash_key> key_len 40 func toeplitz / end" Ticket: 7337
|
Lukas, will you review this ? Should it run CI ? |
|
rss tests: DPDK from v21.11.9 to 24.11.1 master branch: DPDK v20.11.10 master branch: differences are subtle but I attribute it to the different way that RSS is set. On the tested NICs - ice, i40e, mlx5 - it distributes the traffic according to the IPs only, and not according to port changes. ✔️ |
lukashino
requested changes
Feb 2, 2025
| @@ -207,15 +212,26 @@ static void DevicePreClosePMDSpecificActions(DPDKThreadVars *ptv, const char *dr | |||
| } | |||
|
|
|||
| if (strcmp(driver_name, "net_i40e") == 0) { | |||
| #if RTE_VERSION > RTE_VERSION_NUM(20, 0, 0, 0) | |||
| #if RTE_VERSION >= RTE_VERSION_NUM(20, 0, 0, 0) | |||
| // Flush the RSS rules that have been inserted in the post start section | |||
There was a problem hiding this comment.
the code here seems the same right? I would play around the #if to not have code duplication here.
e.g. something like:
if ( \
#if RTE_VERSION > 20
strcmp(..., "net_i40e") == 0 \
#endif
strcmp(... "net_mlx5") == 0 || \
strcmp(... "net_ice") == 0 || \
...
| @@ -1,4 +1,4 @@ | |||
| /* Copyright (C) 2021 Open Information Security Foundation | |||
| /* Copyright (C) 2021-2024 Open Information Security Foundation | |||
There was a problem hiding this comment.
nit: these can get updated to 2025
|
I see it crashes on the SV tests, maybe it just needs a rebase on top of a fresh master. |
|
just tried it and rebasing to master fixes the SV tests. |
3 tasks
|
Continues in #12530 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution style:
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
Our Contribution agreements:
https://suricata.io/about/contribution-agreement/ (note: this is only required once)
Changes (if applicable):
https://redmine.openinfosecfoundation.org/projects/suricata/issues
Link to ticket: https://redmine.openinfosecfoundation.org/issues/7337
Previous PR #12458
Describe changes:
v4
v3
v2
v1
Ticket: #7337