On 6/10/2026 10:31 PM, Zhiping Zhang wrote:
Query dma-buf TPH metadata when registering a dma-buf MR for peer-to-
peer access to a PCIe endpoint and use it to program requester-side TPH
on the outbound mkey. If the exporter has no metadata, fall back to the
existing no-TPH path.
For TPH-backed FRMRs, make the extra ST-table reference belong to the
hardware mkey handle rather than the transient MR object. Extend the
FRMR pool API so reuse and final destroy can transfer and drop that ref
at the handle lifetime boundaries, and add mlx5_st_get_index() to take
a ref on an already-known ST index.
I'd keep the ST reference tied to MRs, where the ST is actually in use.
There's no functional need to couple ST refcounting to mkey lifetime.
Once an MR is destroyed and its mkey revoked, the mkey can no longer
generate traffic, it's just an idle entry in the FRMR pool waiting to be
aged out or reused.
This lets us drop all FRMR pool changes from this patch and keep a
simple flow of 'acquire on MR create, release on MR destroy'.
Also decode PH from kernel_vendor_key when recreating pooled mkeys so
the requester hint matches the pool key.
I've fixed that in a series I've sent earlier this week, please rebase
next version on top of it.
Thanks,
Michael
Signed-off-by: Zhiping Zhang <[email protected]>
---
drivers/infiniband/core/frmr_pools.c | 20 +++-
drivers/infiniband/hw/mlx5/mr.c | 111 +++++++++++++++++-
.../net/ethernet/mellanox/mlx5/core/lib/st.c | 49 ++++++--
include/linux/mlx5/driver.h | 12 ++
include/rdma/frmr_pools.h | 5 +-
5 files changed, 178 insertions(+), 19 deletions(-)
