On Wed, 2016-01-27 at 18:54 +0200, Boaz Harrosh wrote: > On 01/25/2016 11:19 PM, Chuck Lever wrote: > > I'd like to propose a discussion of how to take advantage of > > persistent memory in network-attached storage scenarios. > > > > RDMA runs on high speed network fabrics and offloads data > > transfer from host CPUs. Thus it is a good match to the > > performance characteristics of persistent memory. > > > > Today Linux supports iSER, SRP, and NFS/RDMA on RDMA > > fabrics. What kind of changes are needed in the Linux I/O > > stack (in particular, storage targets) and in these storage > > protocols to get the most benefit from ultra-low latency > > storage? > > > > There have been recent proposals about how storage protocols > > and implementations might need to change (eg. Tom Talpey's > > SNIA proposals for changing to a push data transfer model, > > Sagi's proposal to utilize DAX under the NFS/RDMA server, > > and my proposal for a new pNFS layout to drive RDMA data > > transfer directly). > > > > The outcome of the discussion would be to understand what > > people are working on now and what is the desired > > architectural approach in order to determine where storage > > developers should be focused. > > > > This could be either a BoF or a session during the main > > tracks. There is sure to be a narrow segment of each > > track's attendees that would have interest in this topic. > > > > I would like to attend this talk, and also talk about > a target we have been developing / utilizing that we would like > to propose as a Linux standard driver. For everyone who hasn't sent an attend request in, this is a good example of how not to get an invitation. When collecting the requests to attend, the admins tend to fold to the top of thread, so if you send a request to attend as a reply to somebody else, it won't be seen by that process. You don't need to resend this one, I noticed it, but just in case next time ... James -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
