On 26/08/2019 14:53, Michal Kalderon wrote:
>> From: Jason Gunthorpe <jgg@xxxxxxxx>
>> Sent: Wednesday, August 21, 2019 8:37 PM
>>
>> On Wed, Aug 21, 2019 at 05:14:38PM +0000, Michal Kalderon wrote:
>>
>>>>> Jason, I looked into this deeper today, it seems that since the
>>>>> Core is the one handling the reference counting, and eventually
>>>>> Freeing the object that it makes more sense to keep the allocation
>>>>> In core and not in the drivers, since the driver won't be able to
>>>>> free The entry without providing yet an additional callback
>>>>> function to the Core to be called once the reference count reaches
>> zero.
>>>>
>>>> This already added a callback to free the xa_entry, why can't it
>>>> free all the memory too when kref goes to 0?
>>> True, could free it there. I just think we'll have a bit more
>>> duplication code
>>
>> Well, the drivers already needed to allocate something right?
>>
>>> Between the drivers defining a very similar private structure and
>>> adding Allocation calls before each of the rdma_user_mmap_insert
>> function calls.
>>> And just to make sure I follow,
>>> Do you mean creating the following structure per driver:
>>> Struct <driver>_user_mmap_entry {
>>> struct rdma_user_mmap_entry umap_entry;
>>> ... <private fields> ...
>>> }
>>
>> Yes, that is the general pattern
> Gal,
>
> Following this request from Jason I took another look at the obj that originally
> Was stored in efa_user_mmap_entry, this was used only in debug prints.
> Do you see added value in storing this obj? or do you agree
> We can drop it ?
It originally had more use-cases, we lost them at some point.
I'm fine with removing it, especially if each driver can add his own private
fields to the entry.
