Skip to contentSkip to conversation

net/mlx5: reject negative integrity item configuration

PATCH Superseded Gregory Etelson 2 participants 4 messages Jul 3, 2022 – Jul 4, 2022 Network drivers

lore
Share & tools
lore
#0 lore raw

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
index 9f2832e284..99734157d0 100644
@@ -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
index 09349a021b..bee9363515 100644
@@ -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
#1 lore raw

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
index 9f2832e284..99734157d0 100644
@@ -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
index 09349a021b..bee9363515 100644
@@ -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
#2 lore raw

PATCH v4 1/1 net/mlx5: reject negative integrity item configuration

In reply to Gregory Etelson

From: 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
index 9f2832e284..99734157d0 100644
@@ -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
index 09349a021b..bee9363515 100644
@@ -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
#3 lore raw

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 configuration

From: 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.

Quoted 8 lines

Bugzilla ID: 948

Patch applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh