On Wed, Jul 17, 2019 at 04:35:30PM +0300, Shamir Rabinovitch wrote: > On Wed, Jul 17, 2019 at 2:55 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > > On Wed, Jul 17, 2019 at 02:09:50PM +0300, Shamir Rabinovitch wrote: > > > On Wed, Jul 17, 2019 at 8:09 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > > > On Tue, Jul 16, 2019 at 09:11:35PM +0300, Shamir Rabinovitch 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. > > > > > > > > That sounds like a major complication, so you'd better also explain > > > > the use case very well. > > > > > > The main use case was that there is a server that has giant shared > > > memory that is shared across many processes (lots of mtts). > > > Each process needs the same memory registration (lots of mrs that > > > register same memory). > > > In such scenario, the HCA runs out of mtts. > > > To solve this problem, an single memory registration is shared across > > > all the process in that server saving hca mtts. > > > > Well, why not just share the entire uverbs FD then? Once the PD is > > shared all security is lost anyhow.. > > > > This is not the model that was explained to me last year > > > > Jason > > We do share the whole uvrbs FD (context) with the second process and > let that process to instantiate the PD & MR from the shared FD. > The instantiation include creating new uobject in the second process > context that points to the same ib_x HW objects. > The second process does not own the shared context. > It just use it to get access to the shared ib_x objects and then it > mark those & shared FD as shared. > > What was the expectation from "import_from_xxx" ? None of this discussion makes any sense to me, or matches the use model that I thought this was targetting Jason
