diff mbox series

[1/2] net/mlx5: fix next protocol RSS expansion

Message ID 20220301151856.17341-1-getelson@nvidia.com (mailing list archive)
State Accepted, archived
Delegated to: Raslan Darawsheh
Headers
Series [1/2] net/mlx5: fix next protocol RSS expansion |

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Gregory Etelson March 1, 2022, 3:18 p.m. UTC 
  RSS expansion scheme has 2 operational modes: default and specific.
The default mode expands into all valid options for a given network
layer. For example, Ethernet expands by default into VLAN, IPv4 and
IPv6, L3 expands into TCP and UDP, etc.
The specific mode expands according to flow item next protocol
configuration provided by the item spec and mask parameters.
There are 3 outcomes for the specific expansion:
1.	Back to default – that is the case when result of (spec & mask)
allows all possibilities.
For example: eth type mask 0 type spec 0
2.	No results – in that case item configuration has no valid
expansion. For example: eth type mask 0xffff type spec 101
3.	Direct - In that case flow item mask and spec configuration return
valid expansion  option.
Example: eth type mask 0x0fff type spec 0x0800.

Current PMD expands flow items with explicit spec and mask
configuration into the Direct(3) or No results (2). Default expansions
were handled as No results.

Cc: stable@dpdk.org
Fixes: f3f1f576f438 ("net/mlx5: fix RSS expansion with explicit next protocol")
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
 drivers/net/mlx5/mlx5_flow.c | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Raslan Darawsheh March 2, 2022, 4:41 p.m. UTC | #1 
Hi,

> -----Original Message-----
> From: Gregory Etelson <getelson@nvidia.com>
> Sent: Tuesday, March 1, 2022 5:19 PM
> To: dev@dpdk.org
> Cc: Gregory Etelson <getelson@nvidia.com>; Matan Azrad
> <matan@nvidia.com>; Raslan Darawsheh <rasland@nvidia.com>;
> stable@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>
> Subject: [PATCH 1/2] net/mlx5: fix next protocol RSS expansion
> 
> RSS expansion scheme has 2 operational modes: default and specific.
> The default mode expands into all valid options for a given network layer. For
> example, Ethernet expands by default into VLAN, IPv4 and IPv6, L3 expands
> into TCP and UDP, etc.
> The specific mode expands according to flow item next protocol
> configuration provided by the item spec and mask parameters.
> There are 3 outcomes for the specific expansion:
> 1.	Back to default – that is the case when result of (spec & mask)
> allows all possibilities.
> For example: eth type mask 0 type spec 0
> 2.	No results – in that case item configuration has no valid
> expansion. For example: eth type mask 0xffff type spec 101
> 3.	Direct - In that case flow item mask and spec configuration return
> valid expansion  option.
> Example: eth type mask 0x0fff type spec 0x0800.
> 
> Current PMD expands flow items with explicit spec and mask configuration
> into the Direct(3) or No results (2). Default expansions were handled as No
> results.
> 
> Cc: stable@dpdk.org
> Fixes: f3f1f576f438 ("net/mlx5: fix RSS expansion with explicit next protocol")
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>

Changed the order of the patches, 
Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh
diff mbox series

Patch

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index a690e2d337..0d774cfd19 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -175,6 +175,9 @@  mlx5_nsh_proto_to_item_type(uint8_t proto_spec, uint8_t proto_mask)
 	enum rte_flow_item_type type;
 
 	switch (proto_mask & proto_spec) {
+	case 0:
+		type = RTE_FLOW_ITEM_TYPE_VOID;
+		break;
 	case RTE_VXLAN_GPE_TYPE_IPV4:
 		type = RTE_FLOW_ITEM_TYPE_IPV4;
 		break;
@@ -196,6 +199,9 @@  mlx5_inet_proto_to_item_type(uint8_t proto_spec, uint8_t proto_mask)
 	enum rte_flow_item_type type;
 
 	switch (proto_mask & proto_spec) {
+	case 0:
+		type = RTE_FLOW_ITEM_TYPE_VOID;
+		break;
 	case IPPROTO_UDP:
 		type = RTE_FLOW_ITEM_TYPE_UDP;
 		break;
@@ -221,6 +227,9 @@  mlx5_ethertype_to_item_type(rte_be16_t type_spec,
 	enum rte_flow_item_type type;
 
 	switch (rte_be_to_cpu_16(type_spec & type_mask)) {
+	case 0:
+		type = RTE_FLOW_ITEM_TYPE_VOID;
+		break;
 	case RTE_ETHER_TYPE_TEB:
 		type = is_tunnel ?
 		       RTE_FLOW_ITEM_TYPE_ETH : RTE_FLOW_ITEM_TYPE_END;