Re: [PATCH v11 rdma-next 5/7] RDMA/qedr: Use the common mmap API

Pressman, Gal
2019-09-24T08:50:05Z

> On 23 Sep 2019, at 18:22, Michal Kalderon <mkalderon@marvell.com> wrote:
>
> ﻿
>>
>> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
>> owner@vger.kernel.org> On Behalf Of Gal Pressman
>>
>>> On 19/09/2019 20:55, Jason Gunthorpe wrote:
>>> Huh. If you recall we did all this work with the XA and the free
>>> callback because you said qedr was mmaping BAR pages that had some HW
>>> lifetime associated with them, and the HW resource was not to be
>>> reallocated until all users were gone.
>>>
>>> I think it would be a better example of this API if you pulled the
>>>
>>> dev->ops->rdma_remove_user(dev->rdma_ctx, ctx->dpi);
>>>
>>> Into qedr_mmap_free().
>>>
>>> Then the rdma_user_mmap_entry_remove() will call it naturally as it
>>> does entry_put() and if we are destroying the ucontext we already know
>>> the mmaps are destroyed.
>>>
>>> Maybe the same basic comment for EFA, not sure. Gal?
>>
>> That's what EFA already does in this series, no?
>> We no longer remove entries on dealloc_ucontext, only when the entry is
>> freed.
>
> Actually, I think most of the discussions you had on the topic were with Gal, but
> Some apply to qedr as well, however, for qedr, the only hw resource we allocate (bar)
> is on alloc_ucontext , therefore we were safe to free it on dealloc_ucontext as all mappings
> were already zapped. Making the mmap_free a bit redundant for qedr except for the need
> to free the entry.
>
> For EFA, it seemed the only operation delayed was freeing memory - I didn't see hw resources
> being freed... Gal?

What do you mean by hw resources being freed? The BAR mappings are under the device’s control and are associated to the lifetime of the UAR.