On Thu, Jun 11, 2026 at 5:44 AM Michael Gur <[email protected]> wrote: > > > > > 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
ack, thanks!
