> -----Original Message----- > From: Jason Gunthorpe [mailto:[email protected]] > Sent: Wednesday, July 15, 2015 12:19 PM > To: Chuck Lever > Cc: Sagi Grimberg; Christoph Hellwig; [email protected]; Steve Wise; > Or Gerlitz; Oren Duer; Bart Van Assche; Liran Liss; Hefty, > Sean; Doug Ledford; Tom Talpey > Subject: Re: Kernel fast memory registration API proposal [RFC] > > On Wed, Jul 15, 2015 at 10:32:55AM -0400, Chuck Lever wrote: > > > I would rather not build a non-deterministic delay into the > > unmap interface. Using a pool or having map do an implicit > > unmap are both solutions I’d rather avoid. > > Can you explain how NFS is using FMR today? When does it unmap a FMR > rkey and lkey? > > If NFS/etc currently have a hole on rkey invalidation when using FMR, > and that hole simply cannot reasonably be solved, I'm actually mildly OK > with enshrining that in a new MR API.. > > So, it would seem to me, the only major addition we'd need to Sagi's > draft to support FMR, would be a way to catch the completion (the > rdma_unreg_mr) and trigger async MR recycling async in a work queue. > > Sagi, how does cleanup of the temporary FRMR work in your draft > proposal? What does the ULP do upon completion? > > [Also, just mildly curious, how do we get into an unsleepable > context anyhow? is the IB completion pending callback called in a > sleepable context?] >
>From Documentation/infiniband/core_locking.txt: The context in which completion event and asynchronous event callbacks run is not defined. Depending on the low-level driver, it may be process context, softirq context, or interrupt context. Upper level protocol consumers may not sleep in a callback. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
