On Fri, Feb 24, 2017 at 01:53:21PM -0500, Tom Talpey wrote: > On 2/24/2017 1:25 PM, Jeff Layton wrote: > >v2: comment clarifications, and commit log cleanup. No functional changes. > > > >RFC5661 says: > > > > NFSv4.1 works over Remote Direct Memory Access (RDMA) and non-RDMA- > > based transports with the following attributes: > > > > > > o The transport supports reliable delivery of data, which NFSv4.1 > > requires but neither NFSv4.1 nor RPC has facilities for ensuring > > [34]. > > > > o The transport delivers data in the order it was sent. Ordered > > delivery simplifies detection of transmit errors, and simplifies > > the sending of arbitrary sized requests and responses via the > > record marking protocol [3]. > > > >...and then some hand-wavy stuff about congestion control. RFC7530 > >doesn't mention needing reliable and ordered delivery, but it does need > >congestion control. > > Snipping some stuff for a pedantic response :-) > > There are several good reasons why RFC7530 does not specify reliable and > ordered. OK, I'm dropping "reliable and ordered" from the comments and applying. --b. > The most obvious being, it doesn't need them. Because it has > a session, it can handle out-of-order messages at its layer. This is in > fact critical to supporting trunking and multipathing. And with the > session comes the ability to detect replays, so reliability can be > obviated there too. > > In fact, apart from congestion control, with the proper session support, > NFSv4.1 can run very nicely over an unreliable unordered transport. > Now, NFS4.0, and NFSv3 and NFSv2 before it, are another matter entirely. > > Note that RDMA transports provide remote direct placement only in RC > (Reliable Connected) endpoints, which is why rpcrdma uses that mode. > > Tom. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
