Re: [PATCH v1 00/24] Shared PD and MR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 21, 2019 at 04:37:37PM -0700, Ira Weiny wrote:
> On Wed, Aug 21, 2019 at 05:21:01PM +0300, Yuval Shaia wrote:
> > Following patch-set introduce the shared object feature.
> > 
> > A shared object feature allows one process to create HW objects (currently
> > PD and MR) so that a second process can import.

Hi Ira,

> 
> For something this fundamental I think the cover letter should be more
> detailed than this.  Questions I have without digging into the code:
> 
> What is the use case?

I have only one use case but i didn't added it to commit log just not to
limit the usage of this feature but you are right, cover letter is great
for such things, will add it for v2.

Anyway, here is our use case: Consider a case of server with huge amount
of memory and some hundreds or even thousands processes are using it to
serves clients requests. In this case the HCA will have to manage hundreds
or thousands MRs. A better design maybe would be that one process will
create one (or several) MR(s) which will be shared with the other
processes. This will reduce the number of address translation entries and
cache miss dramatically.

> 
> What is the "key" that allows a MR to be shared among 2 processes?  Do you
> introduce some PD identifier?  And then some {PDID, lkey} tuple is used to ID
> the MR?
> 
> I assume you have to share the PD first and then any MR in the shared PD can be
> shared?  If so how does the MR get shared?

Sorry, i'm not following.
I think the term 'share' is somehow mistake, it is actually a process
'imports' objects into it's context. And yes, the workflow is first to
import the PD and then import the MR.

> 
> Again I'm concerned with how this will interact with the RDMA and file system
> interaction we have been trying to fix.

I'm not aware of this file-system thing, can you point me to some
discussion on that so i'll see how this patch-set affect it.

> 
> Why is SCM_RIGHTS on the rdma context FD not sufficient to share the entire
> context, PD, and all MR's?

Well, this SCM_RIGHTS is great, one can share the IB context with another.
But it is not enough, because:
- What API the second process can use to get his hands on one of the PDs or
  MRs from this context?
- What mechanism takes care of the destruction of such objects (SCM_RIGHTS
  takes care for the ref counting of the context but i'm referring to the
  PDs and MRs objects)?

The entire purpose of this patch set is to address these two questions.

Yuval

> 
> Ira
> 
> > 
> > Patch-set is logically splits to 4 parts as the following:
> > - patches 1 to 7 and 18 are preparation steps.
> > - patches 8 to 14 are the implementation of import PD
> > - patches 15 to 17 are the implementation of the verb
> > - patches 19 to 24 are the implementation of import MR
> > 
> > v0 -> v1:
> > 	* Delete the patch "IB/uverbs: ufile must be freed only when not
> > 	  used anymore". The process can die, the ucontext remains until
> > 	  last reference to it is closed.
> > 	* Rebase to latest for-next branch
> > 
> > Shamir Rabinovitch (16):
> >   RDMA/uverbs: uobj_get_obj_read should return the ib_uobject
> >   RDMA/uverbs: Delete the macro uobj_put_obj_read
> >   RDMA/nldev: ib_pd can be pointed by multiple ib_ucontext
> >   IB/{core,hw}: ib_pd should not have ib_uobject pointer
> >   IB/core: ib_uobject need HW object reference count
> >   IB/uverbs: Helper function to initialize ufile member of
> >     uverbs_attr_bundle
> >   IB/uverbs: Add context import lock/unlock helper
> >   IB/verbs: Prototype of HW object clone callback
> >   IB/mlx4: Add implementation of clone_pd callback
> >   IB/mlx5: Add implementation of clone_pd callback
> >   RDMA/rxe: Add implementation of clone_pd callback
> >   IB/uverbs: Add clone reference counting to ib_pd
> >   IB/uverbs: Add PD import verb
> >   IB/mlx4: Enable import from FD verb
> >   IB/mlx5: Enable import from FD verb
> >   RDMA/rxe: Enable import from FD verb
> > 
> > Yuval Shaia (8):
> >   IB/core: Install clone ib_pd in device ops
> >   IB/core: ib_mr should not have ib_uobject pointer
> >   IB/core: Install clone ib_mr in device ops
> >   IB/mlx4: Add implementation of clone_pd callback
> >   IB/mlx5: Add implementation of clone_pd callback
> >   RDMA/rxe: Add implementation of clone_pd callback
> >   IB/uverbs: Add clone reference counting to ib_mr
> >   IB/uverbs: Add MR import verb
> > 
> >  drivers/infiniband/core/device.c              |   2 +
> >  drivers/infiniband/core/nldev.c               | 127 ++++-
> >  drivers/infiniband/core/rdma_core.c           |  23 +-
> >  drivers/infiniband/core/uverbs.h              |   2 +
> >  drivers/infiniband/core/uverbs_cmd.c          | 489 +++++++++++++++---
> >  drivers/infiniband/core/uverbs_main.c         |   1 +
> >  drivers/infiniband/core/uverbs_std_types_mr.c |   1 -
> >  drivers/infiniband/core/verbs.c               |   4 -
> >  drivers/infiniband/hw/hns/hns_roce_hw_v1.c    |   1 -
> >  drivers/infiniband/hw/mlx4/main.c             |  18 +-
> >  drivers/infiniband/hw/mlx5/main.c             |  34 +-
> >  drivers/infiniband/hw/mthca/mthca_qp.c        |   3 +-
> >  drivers/infiniband/sw/rxe/rxe_verbs.c         |   5 +
> >  include/rdma/ib_verbs.h                       |  43 +-
> >  include/rdma/uverbs_std_types.h               |  11 +-
> >  include/uapi/rdma/ib_user_verbs.h             |  15 +
> >  include/uapi/rdma/rdma_netlink.h              |   3 +
> >  17 files changed, 669 insertions(+), 113 deletions(-)
> > 
> > -- 
> > 2.20.1
> > 



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux