Linux NFS development
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [PATCH v2 11/14] xprtrdma: Fix XDR tail buffer marshalling
Date: Mon, 13 Jul 2015 12:31:26 -0400	[thread overview]
Message-ID: <20150713163126.17630.4327.stgit@manet.1015granger.net> (raw)
In-Reply-To: <20150713160617.17630.97475.stgit@manet.1015granger.net>

Currently xprtrdma appends an extra chunk element to the RPC/RDMA
read chunk list of each NFSv4 WRITE compound. The extra element
contains the final GETATTR operation in the compound.

The result is an extra RDMA READ operation to transfer a very short
piece of each NFS WRITE compound (typically 16 bytes). This is
inefficient.

It is also incorrect. Although RFC 5667 is not precise about when
using a read list with NFSv4 COMPOUND is allowed, the intent is that
only data arguments not touched by NFS (ie, read and write payloads)
are to be sent using RDMA READ or WRITE. The NFS client constructs
GETATTR arguments itself, and therefore is required to send the
trailing GETATTR operation as additional inline content, not as a
data payload.

NB: This change is not backwards compatible. Some older servers do
not accept inline content following the read list. The Linux NFS
server should handle this content correctly as of commit
a97c331f9aa9 ("svcrdma: Handle additional inline content").

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 net/sunrpc/xprtrdma/rpc_rdma.c |   44 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
index 62150ae..1dd48f2 100644
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@ -96,6 +96,42 @@ static bool rpcrdma_results_inline(struct rpc_rqst *rqst)
 	return repsize <= RPCRDMA_INLINE_READ_THRESHOLD(rqst);
 }
 
+static int
+rpcrdma_tail_pullup(struct xdr_buf *buf)
+{
+	size_t tlen = buf->tail[0].iov_len;
+	size_t skip = tlen & 3;
+
+	/* Do not include the tail if it is only an XDR pad */
+	if (tlen < 4)
+		return 0;
+
+	/* xdr_write_pages() adds a pad at the beginning of the tail
+	 * if the content in "buf->pages" is unaligned. Force the
+	 * tail's actual content to land at the next XDR position
+	 * after the head instead.
+	 */
+	if (skip) {
+		unsigned char *src, *dst;
+		unsigned int count;
+
+		src = buf->tail[0].iov_base;
+		dst = buf->head[0].iov_base;
+		dst += buf->head[0].iov_len;
+
+		src += skip;
+		tlen -= skip;
+
+		dprintk("RPC:       %s: skip=%zu, memmove(%p, %p, %zu)\n",
+			__func__, skip, dst, src, tlen);
+
+		for (count = tlen; count; count--)
+			*dst++ = *src++;
+	}
+
+	return tlen;
+}
+
 /*
  * Chunk assembly from upper layer xdr_buf.
  *
@@ -147,6 +183,10 @@ rpcrdma_convert_iovs(struct xdr_buf *xdrbuf, unsigned int pos,
 	if (len && n == nsegs)
 		return -EIO;
 
+	/* When encoding the read list, the tail is always sent inline */
+	if (type == rpcrdma_readch)
+		return n;
+
 	if (xdrbuf->tail[0].iov_len) {
 		/* the rpcrdma protocol allows us to omit any trailing
 		 * xdr pad bytes, saving the server an RDMA operation. */
@@ -476,8 +516,8 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst)
 		headerp->rm_body.rm_nochunks.rm_empty[2] = xdr_zero;
 		/* new length after pullup */
 		rpclen = rqst->rq_svec[0].iov_len;
-	}
-
+	} else if (rtype == rpcrdma_readch)
+		rpclen += rpcrdma_tail_pullup(&rqst->rq_snd_buf);
 	if (rtype != rpcrdma_noch) {
 		hdrlen = rpcrdma_create_chunks(rqst, &rqst->rq_snd_buf,
 					       headerp, rtype);


  parent reply	other threads:[~2015-07-13 16:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13 16:29 [PATCH v2 00/14] NFS/RDMA client side for Linux 4.3 Chuck Lever
2015-07-13 16:29 ` [PATCH v2 01/14] xprtrdma: Make xprt_setup_rdma() agnostic to family of server address Chuck Lever
2015-07-13 16:30 ` [PATCH v2 02/14] xprtrdma: Raise maximum payload size to one megabyte Chuck Lever
2015-07-13 16:30 ` [PATCH v2 03/14] xprtrdma: Increase default credit limit Chuck Lever
2015-07-13 16:30 ` [PATCH v2 04/14] xprtrdma: Don't fall back to PHYSICAL memory registration Chuck Lever
2015-07-13 16:30 ` [PATCH v2 05/14] xprtrdma: Remove last ib_reg_phys_mr() call site Chuck Lever
2015-07-13 16:30 ` [PATCH v2 06/14] xprtrdma: Clean up rpcrdma_ia_open() Chuck Lever
2015-07-13 16:30 ` [PATCH v2 07/14] xprtrdma: Remove logic that constructs RDMA_MSGP type calls Chuck Lever
2015-07-14 19:00   ` Tom Talpey
2015-07-14 19:01     ` Chuck Lever
2015-07-15 18:26       ` Devesh Sharma
2015-07-15 21:29         ` Chuck Lever
2015-07-13 16:30 ` [PATCH v2 08/14] xprtrdma: Account for RPC/RDMA header size when deciding to inline Chuck Lever
2015-07-13 16:31 ` [PATCH v2 09/14] xprtrdma: Always provide a write list when sending NFS READ Chuck Lever
2015-07-13 16:31 ` [PATCH v2 10/14] xprtrdma: Don't provide a reply chunk when expecting a short reply Chuck Lever
2015-07-13 16:31 ` Chuck Lever [this message]
2015-07-13 16:31 ` [PATCH v2 12/14] xprtrdma: Fix large NFS SYMLINK calls Chuck Lever
2015-07-13 16:31 ` [PATCH v2 13/14] xprtrdma: Clean up xprt_rdma_print_stats() Chuck Lever
2015-07-13 16:31 ` [PATCH v2 14/14] xprtrdma: Count RDMA_NOMSG type calls Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150713163126.17630.4327.stgit@manet.1015granger.net \
    --to=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox