[dpdk-stable] patch 'common/mlx5: remove unreachable branch in UAR allocation' has been queued to stable release 20.11.4

[Xueming Li]

Hi,

FYI, your patch has been queued to stable release 20.11.4

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 11/12/21. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/steevenlee/dpdk

This queued commit can be viewed at:
https://github.com/steevenlee/dpdk/commit/d9971e5ae33c9fe7eb4bb48b57573effa2e0e33e

Thanks.

Xueming Li <xuemingl at nvidia.com>

---
>From d9971e5ae33c9fe7eb4bb48b57573effa2e0e33e Mon Sep 17 00:00:00 2001
From: Michael Baum <michaelba at nvidia.com>
Date: Wed, 3 Nov 2021 20:35:09 +0200
Subject: [PATCH] common/mlx5: remove unreachable branch in UAR allocation
Cc: Xueming Li <xuemingl at nvidia.com>

[ upstream commit d1325200ac4de94e804d735f05403d9507343222 ]

The User Access Region (UAR) provides access to the hardware resources
like Doorbell Register from userspace.
It means the resources should be mapped by the kernel to some virtual
address range. There two types of memory mapping are supported by mlx5
kernel driver:

 MLX5DV_UAR_ALLOC_TYPE_NC - non-cached, all writes promoted directly to
			    hardware.
 MLX5DV_UAR_ALLOC_TYPE_BF - "BlueFlame", all writes might be cached by
			    CPU, and will be flushed to hardware
			    explicitly with memory barriers.

The supported mapping types depend on the platform (x86/ARM/etc), kernel
version, driver version, virtualization environment (hypervisor), etc.

In UAR allocation, if the system supports the allocation with non-cached
mapping, the first attempt is performed with MLX5DV_UAR_ALLOC_TYPE_NC.
Then, if this fails, the next attempt is done with
MLX5DV_UAR_ALLOC_TYPE_BF.

However, the function adds a condition for the case where the first
attempt was performed with MLX5DV_UAR_ALLOC_TYPE_BF, a condition that is
unattainable since the first attempt was always performed with
MLX5DV_UAR_ALLOC_TYPE_NC.

Remove the unreachable code.

Fixes: 9cc0e99c81ab0 ("common/mlx5: share UAR allocation routine")

Signed-off-by: Michael Baum <michaelba at nvidia.com>
Reviewed-by: Viacheslav Ovsiienko <viacheslavo at nvidia.com>
Acked-by: Matan Azrad <matan at nvidia.com>
---
 drivers/common/mlx5/mlx5_common.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_common.c b/drivers/common/mlx5/mlx5_common.c
index 4a0992ac8d..0db9882c43 100644
--- a/drivers/common/mlx5/mlx5_common.c
+++ b/drivers/common/mlx5/mlx5_common.c
@@ -248,11 +248,11 @@ mlx5_release_dbr(struct mlx5_dbr_page_list *head, uint32_t umem_id,
  *				attributes (if supported by the host), the
  *				writes to the UAR registers must be followed
  *				by write memory barrier.
- *   MLX5DV_UAR_ALLOC_TYPE_NC - allocate as non-cached nenory, all writes are
+ *   MLX5DV_UAR_ALLOC_TYPE_NC - allocate as non-cached memory, all writes are
  *				promoted to the registers immediately, no
  *				memory barriers needed.
- *   mapping < 0 - the first attempt is performed with MLX5DV_UAR_ALLOC_TYPE_BF,
- *		   if this fails the next attempt with MLX5DV_UAR_ALLOC_TYPE_NC
+ *   mapping < 0 - the first attempt is performed with MLX5DV_UAR_ALLOC_TYPE_NC,
+ *		   if this fails the next attempt with MLX5DV_UAR_ALLOC_TYPE_BF
  *		   is performed. The drivers specifying negative values should
  *		   always provide the write memory barrier operation after UAR
  *		   register writings.
@@ -284,21 +284,7 @@ mlx5_devx_alloc_uar(void *ctx, int mapping)
 #endif
 		uar = mlx5_glue->devx_alloc_uar(ctx, uar_mapping);
 #ifdef MLX5DV_UAR_ALLOC_TYPE_NC
-		if (!uar &&
-		    mapping < 0 &&
-		    uar_mapping == MLX5DV_UAR_ALLOC_TYPE_BF) {
-			/*
-			 * In some environments like virtual machine the
-			 * Write Combining mapped might be not supported and
-			 * UAR allocation fails. We tried "Non-Cached" mapping
-			 * for the case.
-			 */
-			DRV_LOG(WARNING, "Failed to allocate DevX UAR (BF)");
-			uar_mapping = MLX5DV_UAR_ALLOC_TYPE_NC;
-			uar = mlx5_glue->devx_alloc_uar(ctx, uar_mapping);
-		} else if (!uar &&
-			   mapping < 0 &&
-			   uar_mapping == MLX5DV_UAR_ALLOC_TYPE_NC) {
+		if (!uar && mapping < 0) {
 			/*
 			 * If Verbs/kernel does not support "Non-Cached"
 			 * try the "Write-Combining".
-- 
2.33.0

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2021-11-10 14:17:12.543465132 +0800
+++ 0242-common-mlx5-remove-unreachable-branch-in-UAR-allocat.patch	2021-11-10 14:17:02.084077679 +0800
@@ -1 +1 @@
-From d1325200ac4de94e804d735f05403d9507343222 Mon Sep 17 00:00:00 2001
+From d9971e5ae33c9fe7eb4bb48b57573effa2e0e33e Mon Sep 17 00:00:00 2001
@@ -4,0 +5,3 @@
+Cc: Xueming Li <xuemingl at nvidia.com>
+
+[ upstream commit d1325200ac4de94e804d735f05403d9507343222 ]
@@ -34 +36,0 @@
-Cc: stable at dpdk.org
@@ -44 +46 @@
-index 1c36212a04..e8603c7ea9 100644
+index 4a0992ac8d..0db9882c43 100644
@@ -47 +49 @@
-@@ -936,11 +936,11 @@ RTE_INIT_PRIO(mlx5_is_haswell_broadwell_cpu, LOG)
+@@ -248,11 +248,11 @@ mlx5_release_dbr(struct mlx5_dbr_page_list *head, uint32_t umem_id,
@@ -62 +64 @@
-@@ -972,21 +972,7 @@ mlx5_devx_alloc_uar(void *ctx, int mapping)
+@@ -284,21 +284,7 @@ mlx5_devx_alloc_uar(void *ctx, int mapping)