On Thu, 2019-08-22 at 11:41 +0300, Yuval Shaia wrote:
> 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.
Unless I'm misreading you here, it will be at the expense of pretty much
all inter-process memory security. You're talking about one process
creating some large MRs just to cover the overall memory in the machine,
then sharing that among processes, and all using it to reduce the MR
workload of the card. This sounds like going back to the days of MSDos.
It also sounds like a programming error in one process could expose
potentially all processes data buffers across all processes sharing this
PD and MR.
I get the idea, and the problem you are trying to solve, but I'm not
sure that going down this path is wise.
Maybe....maybe if you limit a queue pair to send/recv only and no
rdma_{read,write}, then this wouldn't be quite as bad. But even then
I'm still very leary of this "feature".
>
> > 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
> > >
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
