On 23/08/2021 13:43, Christian König wrote:
Am 21.08.21 um 11:16 schrieb Gal Pressman:I replied to your previous mail, but I'll ask again.
On 20/08/2021 17:32, Jason Gunthorpe wrote:Basically none at all in the framework.
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:Thanks, that makes sense.
Though it would've been nicer if we could agree on a solution that could workI don't think it can really be done, revoke is necessary, and isn't a
for more than 1-2 RDMA devices, using the existing tools the RDMA subsystem
primitive we have today.
Revoke is sort of like rereg MR, but with a guaranteed no-change to
Then there is the locking complexity of linking the mr creation and
destruction to the lifecycle of the pages, which is messy and maybe
not general. For instance mlx5 would call its revoke_mr, disconnect
the dmabuf then destroy the mkey - but this is only safe because mlx5
HW can handle concurrent revokes.
Agree.That's why I tried to approach this by denying such attachments for non-ODPThat is fine if there is no revoke - once revoke exists we must have
importers instead of exposing a "limited" dynamic importer.
driver and HW support.
IIUC, we're talking about three different exporter "types":
- Dynamic with move_notify (requires ODP)
- Dynamic with revoke_notify
Which changes do we need to make the third one work?
You just need to properly use the dma_buf_pin() function when you start using a
buffer (e.g. before you create an attachment) and the dma_buf_unpin() function
after you are done with the DMA-buf.
Doesn't the pin operation migrate the memory to host memory?