Re: [Lsf-pc] [LSF/MM TOPIC/ATTEND] RDMA passive target

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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