Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Michael Gur <michaelgur@nvidia.com>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	Edward Srouji <edwards@nvidia.com>,
	Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH rdma-next 00/15] RDMA: Support HW requiring relaxed ordering and add Unordered access flag
Date: Mon, 10 Aug 2026 16:05:10 +0300	[thread overview]
Message-ID: <20260810130510.GA90355@unreal> (raw)
In-Reply-To: <20260726092943.2880176-1-michaelgur@nvidia.com>

On Sun, Jul 26, 2026 at 12:29:14PM +0300, Michael Gur wrote:
> This series prepares the mlx5 stack for hardware that restricts strong-
> ordered memory accesses, i.e. HW whose fabric doesn't guarantee memory
> operation ordering. The HW may choose to reject creation of an mkey that
> doesn't request relaxed ordering, so every mkey the driver creates -
> internal and user-facing - has to be handled accordingly.
> 
> The previously added 'ConnectX-10 NVLink-C2C' PCI device is such a device,
> as will be any future PCIe Gen7 UIO devices. 
> 
> The series does four things:
> 
> 1. Allow optional access flags on all memory registration
>    The uverbs ABI defines the optional access flags range as best-effort:
>    drivers must accept any flag in this range and treat support as
>    opportunistic, never failing registration. Several registration paths
>    (DM, DEVX UMEM, dmabuf ioctl, reg_mr ioctl) did not allow this range
>    and would reject such requests. These are fixed to allow newly added
>    optional access flag added later in the series and any future optional
>    access flag.
> 
> 2. Groundwork and internal mkeys
>    Rename the relaxed-ordering IFC fields to the new naming, add the new
>    ordering capability and mkey-context bits, and consolidate RO-setting
>    to a single helper in mlx5_core so all consumers share one cap-gated
>    implementation. Then enable relaxed ordering on the internal mkeys that
>    don't require strong ordering (resource dump, vfio live-migration data,
>    ODP null mkey, memory window mkey), so they keep working on strict-RO
>    HW.
> 
> 3. New Unordered access flag and enforcement
>    Add IB_ACCESS_UNORDERED, an optional access flag that additionally
>    allows read-after-write reordering, and wire up mlx5 support for it.
> 
> 4. Enforce no-strong-ordering in user MR registration on HW that requires
>    it.
> 
> Michael Gur (15):
>   RDMA/mlx5: Allow optional access flags in DM registration
>   RDMA/mlx5: Allow optional access flags in DEVX UMEM registration
>   RDMA/core: Allow optional access flags in dmabuf reg ioctl
>   RDMA/core: Allow optional access flags in reg mr ioctl
>   mlx5: Rename IFC bits of relaxed ordering fields
>   net/mlx5: Add IFC bits for new ordering caps
>   mlx5: Move RO setting helper to core and consolidate mlx5 consumers
>   net/mlx5: Enable relaxed ordering on resource dump mkey
>   vfio/mlx5: Enable relaxed ordering on the live migration data mkey
>   RDMA/mlx5: Enable relaxed ordering on ODP null mkey
>   RDMA/mlx5: Enable relaxed ordering on Memory Window mkey on strict-RO
>     HW
>   RDMA/mlx5: Converge UMR access-flag cap checks
>   RDMA/uverbs: Add new Unordered MR access flag
>   RDMA/mlx5: Support new Unordered access flag
>   RDMA/mlx5: Enforce relaxed ordering when HW requires it
> 
>  drivers/infiniband/core/umem.c                |  2 +-
>  drivers/infiniband/core/uverbs_std_types_mr.c |  4 +-
>  drivers/infiniband/hw/mlx5/devx.c             |  2 +-
>  drivers/infiniband/hw/mlx5/main.c             |  8 +-
>  drivers/infiniband/hw/mlx5/mlx5_ib.h          |  4 +-
>  drivers/infiniband/hw/mlx5/mr.c               | 79 ++++++++++---------
>  drivers/infiniband/hw/mlx5/odp.c              |  1 +
>  drivers/infiniband/hw/mlx5/umr.c              | 18 ++---
>  drivers/infiniband/hw/mlx5/umr.h              | 45 ++++++-----
>  .../mellanox/mlx5/core/diag/rsc_dump.c        |  1 +
>  drivers/net/ethernet/mellanox/mlx5/core/en.h  |  1 -
>  .../ethernet/mellanox/mlx5/core/en/params.c   |  2 +-
>  .../ethernet/mellanox/mlx5/core/en_common.c   | 13 +--
>  .../net/ethernet/mellanox/mlx5/core/en_main.c |  4 +-
>  drivers/net/ethernet/mellanox/mlx5/core/mr.c  | 21 +++++
>  drivers/vfio/pci/mlx5/cmd.c                   |  7 +-
>  include/linux/mlx5/driver.h                   |  1 +
>  include/linux/mlx5/mlx5_ifc.h                 | 24 ++++--
>  include/rdma/ib_verbs.h                       |  1 +
>  include/uapi/rdma/ib_user_ioctl_verbs.h       |  1 +
>  20 files changed, 134 insertions(+), 105 deletions(-)

Sashiko is not happy about this series.

Thanks

> 
> -- 
> 2.52.0
> 

  parent reply	other threads:[~2026-08-10 13:05 UTC|newest]

Thread overview: 33+ 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-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 02/15] RDMA/mlx5: Allow optional access flags in DEVX UMEM registration Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 03/15] RDMA/core: Allow optional access flags in dmabuf reg ioctl Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 04/15] RDMA/core: Allow optional access flags in reg mr ioctl Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 05/15] mlx5: Rename IFC bits of relaxed ordering fields Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 06/15] net/mlx5: Add IFC bits for new ordering caps Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 07/15] mlx5: Move RO setting helper to core and consolidate mlx5 consumers Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 08/15] net/mlx5: Enable relaxed ordering on resource dump mkey Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 09/15] vfio/mlx5: Enable relaxed ordering on the live migration data mkey Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 10/15] RDMA/mlx5: Enable relaxed ordering on ODP null mkey Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
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-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 12/15] RDMA/mlx5: Converge UMR access-flag cap checks Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 13/15] RDMA/uverbs: Add new Unordered MR access flag Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 14/15] RDMA/mlx5: Support new Unordered " Michael Gur
2026-08-11 19:31   ` Jason Gunthorpe
2026-07-26  9:29 ` [PATCH rdma-next 15/15] RDMA/mlx5: Enforce relaxed ordering when HW requires it Michael Gur
2026-08-10 13:05 ` Leon Romanovsky [this message]
2026-08-10 13:27   ` [PATCH rdma-next 00/15] RDMA: Support HW requiring relaxed ordering and add Unordered access flag Michael Gur
2026-08-11 19:31 ` Jason Gunthorpe

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=20260810130510.GA90355@unreal \
    --to=leon@kernel.org \
    --cc=edwards@nvidia.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michaelgur@nvidia.com \
    --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