Thread (33 messages) flat view 33 messages, 3 authors, 29d ago

Re: [PATCH rdma-next 07/15] mlx5: Move RO setting helper to core and consolidate mlx5 consumers

From: Jason Gunthorpe <jgg@nvidia.com>
Date: 2026-08-11 19:32:21
Also in: linux-rdma, lkml

Move mlx5e_mkey_set_relaxed_ordering() from en_common.c to core/mr.c
as mlx5_core_mkey_set_relaxed_ordering() and export it. The helper
centralizes the cap gating for order_write_after_write and
pci_relaxed_ordered_read so each consumer no longer has to open-code
the same dance.

Switch the static MR creation path (set_mkc_access_pd_addr_fields)
and the UMR access-modify path (mlx5r_umr_set_access_flags) over to
the new helper. Both call it inside the IB_ACCESS_RELAXED_ORDERING
gate, preserving their existing conditional semantics: RO bits are
only written when the caller actually requested RO. The Ethernet
path already uses the helper unconditionally on every internal mkey
it creates.

Consolidating onto the helper has two benefits beyond the
deduplication itself:
  * pcie_relaxed_ordering_enabled() is now invoked only when the
    caller requests RO, avoiding pci_lock contention on every MR
    registration.
This is wrong anyhow, we shouldn't be checking PCI state in these methods,
the same we don't check PCI ATS state or anything else.

If the FW supports the MKC bit it should accept it in the MKC and it is
entirely fine if the FW decides to ignore it.

But at least as much as a code movement goes this looks OK

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

-- 
Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help