net/mlx5: reject negative integrity item configuration
PATCH 1/1 net/mlx5: reject negative integrity item configuration
Negative integrity item refers to condition when the item value mask is set, but value spec is cleared:
... integrity value mask l4_ok value spec 0 ...
RTE library defines integrity bits l3_ok and l4_ok as accumulators for all hardware L3 and L4 integrity verifications respectfully. Hardware l3_ok and l4_ok integrity bits refer to L3 and L4 network headers only.
Integrity bits l3_ok and l4_ok are not compatible between RTE library and hardware.
PMD translations for RTE l3_ok are:
IPv4: l3_ok and l3_csum_ok
IPv6: l3_ok
RTE l4_ok is translated into PMD l4_ok and l4_csum_ok bits.
Positive IPv4 l3_ok flow item configuration is translated into a single matcher that AND corresponding hardware bits. Negative IPv4 l3_ok is translated into 2 hardware conditions where each condition probes a single integrity bit:
RTE::l3_ok is 0 => MLX5::l3_ok is 0 OR MLX5:l3_csum_ok is 0
MLX5 hardware does not do OR condition in flow rule item. Negative IPv4 l3_ok must be translated into 2 flow rules. Similarly negative RTE l4_ok condition is also translated into 2 hardware rules.
Current PMD roadmap does not allow implicit flow rule split.
TODO: extend RTE integrity bits definition to allow match on each hardware integrity bit for accumulated integiry matches.
Bugzilla ID: 948
--- doc/guides/nics/mlx5.rst | 5 +++-- drivers/net/mlx5/mlx5_flow_dv.c | 6 ++++++ 2 files changed, 9 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +3 -2
@@ -479,14 +479,15 @@ Limitations - Integrity offload is enabled starting from **ConnectX-6 Dx**. - Verification bits provided by the hardware are ``l3_ok``, ``ipv4_csum_ok``, ``l4_ok``, ``l4_csum_ok``. - ``level`` value 0 references outer headers. + - Negative integrity item verification is not supported - Multiple integrity items not supported in a single flow rule. - Flow rule items supplied by application must explicitly specify network headers referred by integrity item. For example, if integrity item mask sets ``l4_ok`` or ``l4_csum_ok`` bits, reference to L4 network header, TCP or UDP, must be in the rule pattern as well:: flow create 0 ingress pattern integrity level is 0 value mask l3_ok value spec l3_ok / eth / ipv6 / end … - or - flow create 0 ingress pattern integrity level is 0 value mask l4_ok value spec 0 / eth / ipv4 proto is udp / end … + + flow create 0 ingress pattern integrity level is 0 value mask l4_ok value spec l4_ok / eth / ipv4 proto is udp / end … - Connection tracking:
drivers/net/mlx5/mlx5_flow_dv.c +6 -0
@@ -6779,6 +6779,12 @@ flow_dv_validate_item_integrity(struct rte_eth_dev *dev,RTE_FLOW_ERROR_TYPE_ITEM , integrity_item, "unsupported integrity filter"); +if ((mask->l3_ok & !spec->l3_ok) || (mask->l4_ok & !spec->l4_ok) || + (mask->ipv4_csum_ok & !spec->ipv4_csum_ok) || + (mask->l4_csum_ok & !spec->l4_csum_ok)) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , +NULL ,"negative integrity flow is not supported" );if (spec->level >1 ) {if (pattern_flags &MLX5_FLOW_ITEM_INNER_INTEGRITY )return rte_flow_error_set
Signature · 1 line
2.34.1
PATCH v2 1/1 net/mlx5: reject negative integrity item configuration
Negative integrity item refers to condition when the item value mask is set, but value spec is cleared:
... integrity value mask l4_ok value spec 0 ...
RTE library defines integrity bits l3_ok and l4_ok as accumulators for all hardware L3 and L4 integrity verifications respectfully. Hardware l3_ok and l4_ok integrity bits refer to L3 and L4 network headers only.
Integrity bits l3_ok and l4_ok are not compatible between RTE library and hardware.
PMD translations for RTE l3_ok are:
IPv4: l3_ok and l3_csum_ok
IPv6: l3_ok
RTE l4_ok is translated into PMD l4_ok and l4_csum_ok bits.
Positive IPv4 l3_ok flow item configuration is translated into a single matcher that AND corresponding hardware bits. Negative IPv4 l3_ok is translated into 2 hardware conditions where each condition probes a single integrity bit:
RTE::l3_ok is 0 => MLX5::l3_ok is 0 OR MLX5:l3_csum_ok is 0
MLX5 hardware does not do OR condition in flow rule item. Negative IPv4 l3_ok must be translated into 2 flow rules. Similarly negative RTE l4_ok condition is also translated into 2 hardware rules.
Current PMD roadmap does not allow implicit flow rule split.
TODO: extend RTE integrity bits definition to allow match on each hardware integrity bit for accumulated integiry matches.
Bugzilla ID: 948
---
v2: fix typo in cc address
--- doc/guides/nics/mlx5.rst | 5 +++-- drivers/net/mlx5/mlx5_flow_dv.c | 6 ++++++ 2 files changed, 9 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +3 -2
@@ -479,14 +479,15 @@ Limitations - Integrity offload is enabled starting from **ConnectX-6 Dx**. - Verification bits provided by the hardware are ``l3_ok``, ``ipv4_csum_ok``, ``l4_ok``, ``l4_csum_ok``. - ``level`` value 0 references outer headers. + - Negative integrity item verification is not supported - Multiple integrity items not supported in a single flow rule. - Flow rule items supplied by application must explicitly specify network headers referred by integrity item. For example, if integrity item mask sets ``l4_ok`` or ``l4_csum_ok`` bits, reference to L4 network header, TCP or UDP, must be in the rule pattern as well:: flow create 0 ingress pattern integrity level is 0 value mask l3_ok value spec l3_ok / eth / ipv6 / end … - or - flow create 0 ingress pattern integrity level is 0 value mask l4_ok value spec 0 / eth / ipv4 proto is udp / end … + + flow create 0 ingress pattern integrity level is 0 value mask l4_ok value spec l4_ok / eth / ipv4 proto is udp / end … - Connection tracking:
drivers/net/mlx5/mlx5_flow_dv.c +6 -0
@@ -6779,6 +6779,12 @@ flow_dv_validate_item_integrity(struct rte_eth_dev *dev,RTE_FLOW_ERROR_TYPE_ITEM , integrity_item, "unsupported integrity filter"); +if ((mask->l3_ok & !spec->l3_ok) || (mask->l4_ok & !spec->l4_ok) || + (mask->ipv4_csum_ok & !spec->ipv4_csum_ok) || + (mask->l4_csum_ok & !spec->l4_csum_ok)) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , +NULL ,"negative integrity flow is not supported" );if (spec->level >1 ) {if (pattern_flags &MLX5_FLOW_ITEM_INNER_INTEGRITY )return rte_flow_error_set
Signature · 1 line
2.34.1
PATCH v4 1/1 net/mlx5: reject negative integrity item configuration
In reply to Gregory EtelsonFrom: Raja Zidane <[email protected]>
Negative integrity item refers to condition when the item value mask is set, but value spec is cleared:
... integrity value mask l4_ok value spec 0 ...
RTE library defines integrity bits l3_ok and l4_ok as accumulators for all hardware L3 and L4 integrity verifications respectfully. Hardware l3_ok and l4_ok integrity bits refer to L3 and L4 network headers only.
Integrity bits l3_ok and l4_ok are not compatible between RTE library and hardware.
PMD translations for RTE l3_ok are:
IPv4: l3_ok and l3_csum_ok
IPv6: l3_ok
RTE l4_ok is translated into PMD l4_ok and l4_csum_ok bits.
Positive IPv4 l3_ok flow item configuration is translated into a single matcher that AND corresponding hardware bits. Negative IPv4 l3_ok is translated into 2 hardware conditions where each condition probes a single integrity bit:
RTE::l3_ok is 0 => MLX5::l3_ok is 0 OR MLX5:l3_csum_ok is 0
MLX5 hardware does not do OR condition in flow rule item. Negative IPv4 l3_ok must be translated into 2 flow rules. Similarly negative RTE l4_ok condition is also translated into 2 hardware rules.
Current PMD roadmap does not allow implicit flow rule split.
TODO: extend RTE integrity bits definition to allow match on each hardware integrity bit for accumulated integiry matches.
Bugzilla ID: 948
---
v2: fix typo in cc address.
v3:
V4: fix author and version id.
--- doc/guides/nics/mlx5.rst | 5 +++-- drivers/net/mlx5/mlx5_flow_dv.c | 6 ++++++ 2 files changed, 9 insertions(+), 2 deletions(-)
doc/guides/nics/mlx5.rst +3 -2
@@ -479,14 +479,15 @@ Limitations - Integrity offload is enabled starting from **ConnectX-6 Dx**. - Verification bits provided by the hardware are ``l3_ok``, ``ipv4_csum_ok``, ``l4_ok``, ``l4_csum_ok``. - ``level`` value 0 references outer headers. + - Negative integrity item verification is not supported - Multiple integrity items not supported in a single flow rule. - Flow rule items supplied by application must explicitly specify network headers referred by integrity item. For example, if integrity item mask sets ``l4_ok`` or ``l4_csum_ok`` bits, reference to L4 network header, TCP or UDP, must be in the rule pattern as well:: flow create 0 ingress pattern integrity level is 0 value mask l3_ok value spec l3_ok / eth / ipv6 / end … - or - flow create 0 ingress pattern integrity level is 0 value mask l4_ok value spec 0 / eth / ipv4 proto is udp / end … + + flow create 0 ingress pattern integrity level is 0 value mask l4_ok value spec l4_ok / eth / ipv4 proto is udp / end … - Connection tracking:
drivers/net/mlx5/mlx5_flow_dv.c +6 -0
@@ -6779,6 +6779,12 @@ flow_dv_validate_item_integrity(struct rte_eth_dev *dev,RTE_FLOW_ERROR_TYPE_ITEM , integrity_item, "unsupported integrity filter"); +if ((mask->l3_ok & !spec->l3_ok) || (mask->l4_ok & !spec->l4_ok) || + (mask->ipv4_csum_ok & !spec->ipv4_csum_ok) || + (mask->l4_csum_ok & !spec->l4_csum_ok)) +return rte_flow_error_set (error,EINVAL , +RTE_FLOW_ERROR_TYPE_ITEM , +NULL ,"negative integrity flow is not supported" );if (spec->level >1 ) {if (pattern_flags &MLX5_FLOW_ITEM_INNER_INTEGRITY )return rte_flow_error_set
Signature · 1 line
2.34.1
Hi,
Quoted 43 lines
-----Original Message-----
From: Gregory Etelson <[email protected]>
Sent: Monday, July 4, 2022 1:12 PM
To: [email protected]
Cc: Gregory Etelson <[email protected]>; Matan Azrad <[email protected]>; Raslan Darawsheh <[email protected]>; Raja Zidane <[email protected]>; [email protected]; Slava Ovsiienko <[email protected]>
Subject: [PATCH v4] net/mlx5: reject negative integrity item configurationFrom: Raja Zidane <[email protected]>
Negative integrity item refers to condition when the item value mask is set, but value spec is cleared:
... integrity value maskl4_okvalue spec 0 ...RTE library defines integrity bits
l3_okandl4_okas accumulators for all hardware L3 and L4 integrity verifications respectfully. Hardwarel3_okandl4_okintegrity bits refer to L3 and L4 network headers only.
Integrity bitsl3_okandl4_okare not compatible between RTE library and hardware.PMD translations for RTE
l3_okare:
IPv4:l3_okandl3_csum_ok
IPv6:l3_ok
RTEl4_okis translated into PMDl4_okandl4_csum_okbits.Positive IPv4
l3_okflow item configuration is translated into a single matcher that AND corresponding hardware bits. Negative IPv4l3_okis translated into 2 hardware conditions where each condition probes a single integrity bit:
RTE::l3_okis 0 =>MLX5::l3_okis 0 OR MLX5:l3_csum_ok is 0
MLX5 hardware does not do OR condition in flow rule item. Negative IPv4l3_okmust be translated into 2 flow rules. Similarly negative RTEl4_okcondition is also translated into 2 hardware rules.Current PMD roadmap does not allow implicit flow rule split.
TODO: extend RTE integrity bits definition to allow match on each hardware integrity bit for accumulated integiry matches.
Quoted 8 lines
Bugzilla ID: 948
Proposed-off-by Raja Zidane [email protected]Signed-off-by Gregory Etelson <[email protected]>Acked-by Matan Azrad <[email protected]>
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh