On 23/08/2021 13:43, Christian König wrote: > Am 21.08.21 um 11:16 schrieb Gal Pressman: >> On 20/08/2021 17:32, Jason Gunthorpe wrote: >>> On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote: >>> >>>> Though it would've been nicer if we could agree on a solution that could work >>>> for more than 1-2 RDMA devices, using the existing tools the RDMA subsystem >>>> has. >>> I don't think it can really be done, revoke is necessary, and isn't a >>> primitive we have today. >>> >>> Revoke is sort of like rereg MR, but with a guaranteed no-change to >>> the lkey/rkey >>> >>> 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. >> Thanks, that makes sense. >> >>>> That's why I tried to approach this by denying such attachments for non-ODP >>>> importers instead of exposing a "limited" dynamic importer. >>> That is fine if there is no revoke - once revoke exists we must have >>> driver and HW support. >> Agree. >> IIUC, we're talking about three different exporter "types": >> - Dynamic with move_notify (requires ODP) >> - Dynamic with revoke_notify >> - Static >> >> Which changes do we need to make the third one work? > > Basically none at all in the framework. > > 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. I replied to your previous mail, but I'll ask again. Doesn't the pin operation migrate the memory to host memory?
