Netdev List
 help / color / mirror / Atom feed
From: Michael Gur <michaelgur@nvidia.com>
To: jgg@ziepe.ca, leon@kernel.org
Cc: linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	Edward Srouji <edwards@nvidia.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Michael Gur <michaelgur@nvidia.com>,
	linux-kernel@vger.kernel.org (open list)
Subject: [PATCH rdma-next 12/15] RDMA/mlx5: Converge UMR access-flag cap checks
Date: Sun, 26 Jul 2026 12:29:26 +0300	[thread overview]
Message-ID: <20260726092943.2880176-13-michaelgur@nvidia.com> (raw)
In-Reply-To: <20260726092943.2880176-1-michaelgur@nvidia.com>

Move the UMR cap check from both MR registration and UMR paths to a
single helper checking the access flags non-modifiable by UMR.

No behavior change for the current flag set.
Converge to prevent code duplication when adding support to new access
flags that are not modifiable by UMR, like the new Unordered access flag
added in following patches.

Reviewed-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Michael Gur <michaelgur@nvidia.com>
---
 drivers/infiniband/hw/mlx5/mr.c  | 30 +++-----------------------
 drivers/infiniband/hw/mlx5/umr.h | 37 ++++++++++++++++++--------------
 2 files changed, 24 insertions(+), 43 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 29a9da5c6dca..5f6d91c47483 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -128,30 +128,6 @@ static int get_mkc_octo_size(unsigned int access_mode, unsigned int ndescs)
 	return ret;
 }
 
-static int get_unchangeable_access_flags(struct mlx5_ib_dev *dev,
-					 int access_flags)
-{
-	int ret = 0;
-
-	if ((access_flags & IB_ACCESS_REMOTE_ATOMIC) &&
-	    MLX5_CAP_GEN(dev->mdev, atomic) &&
-	    MLX5_CAP_GEN(dev->mdev, umr_modify_atomic_disabled))
-		ret |= IB_ACCESS_REMOTE_ATOMIC;
-
-	if ((access_flags & IB_ACCESS_RELAXED_ORDERING) &&
-	    MLX5_CAP_GEN(dev->mdev, mkc_order_write_after_write_ro) &&
-	    !MLX5_CAP_GEN(dev->mdev, order_write_after_write_umr))
-		ret |= IB_ACCESS_RELAXED_ORDERING;
-
-	if ((access_flags & IB_ACCESS_RELAXED_ORDERING) &&
-	    (MLX5_CAP_GEN(dev->mdev, pci_relaxed_ordered_read) ||
-	     MLX5_CAP_GEN(dev->mdev, relaxed_ordering_read_pci_enabled)) &&
-	    !MLX5_CAP_GEN(dev->mdev, pci_relaxed_ordered_read_umr))
-		ret |= IB_ACCESS_RELAXED_ORDERING;
-
-	return ret;
-}
-
 #define MLX5_FRMR_POOLS_KEY_ACCESS_MODE_KSM_MASK 1ULL
 #define MLX5_FRMR_POOLS_KEY_VENDOR_KEY_SUPPORTED \
 	MLX5_FRMR_POOLS_KEY_ACCESS_MODE_KSM_MASK
@@ -173,7 +149,7 @@ _mlx5_frmr_pool_alloc(struct mlx5_ib_dev *dev, struct ib_umem *umem,
 
 	mr->ibmr.frmr.key.ats = mlx5_umem_needs_ats(dev, umem, access_flags);
 	mr->ibmr.frmr.key.access_flags =
-		get_unchangeable_access_flags(dev, access_flags);
+		mlx5r_umr_get_unchangeable_access_flags(dev, access_flags);
 	mr->ibmr.frmr.key.num_dma_blocks =
 		ib_umem_num_dma_blocks(umem, page_size);
 	mr->ibmr.frmr.key.vendor_key =
@@ -205,7 +181,7 @@ struct mlx5_ib_mr *mlx5_mr_cache_alloc(struct mlx5_ib_dev *dev,
 {
 	struct ib_frmr_key key = {
 		.access_flags =
-			get_unchangeable_access_flags(dev, access_flags),
+			mlx5r_umr_get_unchangeable_access_flags(dev, access_flags),
 		.vendor_key = access_mode == MLX5_MKC_ACCESS_MODE_MTT ?
 				      0 :
 				      MLX5_FRMR_POOLS_KEY_ACCESS_MODE_KSM_MASK,
@@ -324,7 +300,7 @@ static int mlx5r_build_frmr_key(struct ib_device *device,
 
 	out->ats = in->ats;
 	out->access_flags =
-		get_unchangeable_access_flags(dev, in->access_flags);
+		mlx5r_umr_get_unchangeable_access_flags(dev, in->access_flags);
 	out->vendor_key = in->vendor_key;
 	out->num_dma_blocks = in->num_dma_blocks;
 
diff --git a/drivers/infiniband/hw/mlx5/umr.h b/drivers/infiniband/hw/mlx5/umr.h
index 04dec726b267..a6c4f35b75e6 100644
--- a/drivers/infiniband/hw/mlx5/umr.h
+++ b/drivers/infiniband/hw/mlx5/umr.h
@@ -44,34 +44,39 @@ static inline bool mlx5r_umr_can_load_pas(struct mlx5_ib_dev *dev,
 	return true;
 }
 
-/*
- * true if an existing MR can be reconfigured to new access_flags using UMR.
- * Older HW cannot use UMR to update certain elements of the MKC. See
- * get_umr_update_access_mask() and umr_check_mkey_mask()
- */
-static inline bool mlx5r_umr_can_reconfig(struct mlx5_ib_dev *dev,
-					  unsigned int current_access_flags,
-					  unsigned int target_access_flags)
+/* Return subset of access_flags whose mkey fields can't be updated via UMR. */
+static inline unsigned int
+mlx5r_umr_get_unchangeable_access_flags(struct mlx5_ib_dev *dev,
+					unsigned int access_flags)
 {
-	unsigned int diffs = current_access_flags ^ target_access_flags;
+	unsigned int ret = 0;
 
-	if ((diffs & IB_ACCESS_REMOTE_ATOMIC) &&
+	if ((access_flags & IB_ACCESS_REMOTE_ATOMIC) &&
 	    MLX5_CAP_GEN(dev->mdev, atomic) &&
 	    MLX5_CAP_GEN(dev->mdev, umr_modify_atomic_disabled))
-		return false;
+		ret |= IB_ACCESS_REMOTE_ATOMIC;
 
-	if ((diffs & IB_ACCESS_RELAXED_ORDERING) &&
+	if ((access_flags & IB_ACCESS_RELAXED_ORDERING) &&
 	    MLX5_CAP_GEN(dev->mdev, mkc_order_write_after_write_ro) &&
 	    !MLX5_CAP_GEN(dev->mdev, order_write_after_write_umr))
-		return false;
+		ret |= IB_ACCESS_RELAXED_ORDERING;
 
-	if ((diffs & IB_ACCESS_RELAXED_ORDERING) &&
+	if ((access_flags & IB_ACCESS_RELAXED_ORDERING) &&
 	    (MLX5_CAP_GEN(dev->mdev, pci_relaxed_ordered_read) ||
 	     MLX5_CAP_GEN(dev->mdev, relaxed_ordering_read_pci_enabled)) &&
 	    !MLX5_CAP_GEN(dev->mdev, pci_relaxed_ordered_read_umr))
-		return false;
+		ret |= IB_ACCESS_RELAXED_ORDERING;
 
-	return true;
+	return ret;
+}
+
+/* true if an existing MR can be reconfigured to new access_flags using UMR. */
+static inline bool mlx5r_umr_can_reconfig(struct mlx5_ib_dev *dev,
+					  unsigned int current_access_flags,
+					  unsigned int target_access_flags)
+{
+	return mlx5r_umr_get_unchangeable_access_flags(
+		dev, current_access_flags ^ target_access_flags) == 0;
 }
 
 static inline u64 mlx5r_umr_get_xlt_octo(u64 bytes)
-- 
2.52.0


  parent reply	other threads:[~2026-07-26  9:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26  9:29 [PATCH rdma-next 00/15] RDMA: Support HW requiring relaxed ordering and add Unordered access flag Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 01/15] RDMA/mlx5: Allow optional access flags in DM registration Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 02/15] RDMA/mlx5: Allow optional access flags in DEVX UMEM registration Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 03/15] RDMA/core: Allow optional access flags in dmabuf reg ioctl Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 04/15] RDMA/core: Allow optional access flags in reg mr ioctl Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 05/15] mlx5: Rename IFC bits of relaxed ordering fields Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 06/15] net/mlx5: Add IFC bits for new ordering caps Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 07/15] mlx5: Move RO setting helper to core and consolidate mlx5 consumers Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 08/15] net/mlx5: Enable relaxed ordering on resource dump mkey Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 09/15] vfio/mlx5: Enable relaxed ordering on the live migration data mkey Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 10/15] RDMA/mlx5: Enable relaxed ordering on ODP null mkey Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 11/15] RDMA/mlx5: Enable relaxed ordering on Memory Window mkey on strict-RO HW Michael Gur
2026-07-26  9:29 ` Michael Gur [this message]
2026-07-26  9:29 ` [PATCH rdma-next 13/15] RDMA/uverbs: Add new Unordered MR access flag Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 14/15] RDMA/mlx5: Support new Unordered " Michael Gur
2026-07-26  9:29 ` [PATCH rdma-next 15/15] RDMA/mlx5: Enforce relaxed ordering when HW requires it Michael Gur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260726092943.2880176-13-michaelgur@nvidia.com \
    --to=michaelgur@nvidia.com \
    --cc=edwards@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yishaih@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox