common/mlx5: remove unreachable branch in UAR allocation

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")
Cc: stable@dpdk.org
Signed-off-by: Michael Baum <michaelba@nvidia.com>
Reviewed-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>

diff --git a/drivers/common/mlx5/mlx5_common.c b/drivers/common/mlx5/mlx5_common.c
index 1c36212a0463f44b2b9902b7a4d2e73e0099ed71..e8603c7ea9822d6bb88ef03c905b800db2c8e266 100644 (file)
--- a/drivers/common/mlx5/mlx5_common.c
+++ b/drivers/common/mlx5/mlx5_common.c
@@ -936,11 +936,11 @@ RTE_INIT_PRIO(mlx5_is_haswell_broadwell_cpu, LOG)
  *                             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.
@@ -972,21 +972,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".