> 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 ?
Thanks,
Michal
>
> Jaosn
