]> www.infradead.org Git - users/jedix/linux-maple.git/commit
xprtrdma: Remove logic that constructs RDMA_MSGP type calls
authorChuck Lever <chuck.lever@oracle.com>
Fri, 10 Jul 2015 20:06:30 +0000 (16:06 -0400)
committerChuck Lever <chuck.lever@oracle.com>
Mon, 31 Aug 2015 20:45:59 +0000 (14:45 -0600)
commit8ffe2940cff12fa8f37cea6bb939c244af36354e
treee1055876a51bab1da362895cf8a3a4d6f3606089
parentc34af297589184dc01c3881a841c9d5696bf4e57
xprtrdma: Remove logic that constructs RDMA_MSGP type calls

[ Queued for upstream v4.3 ]

RDMA_MSGP type calls insert a zero pad in the middle of the RPC
message to align the RPC request's data payload to the server's
alignment preferences. A server can then "page flip" the payload
into place to avoid a data copy in certain circumstances. However:

1. The client has to have a priori knowledge of the server's
   preferred alignment

2. Requests eligible for RDMA_MSGP are requests that are small
   enough to have been sent inline, and convey a data payload
   at the _end_ of the RPC message

Today 1. is done with a sysctl, and is a global setting that is
copied during mount. Linux does not support CCP to query the
server's preferences (RFC 5666, Section 6).

A small-ish NFSv3 WRITE might use RDMA_MSGP, but no NFSv4
compound fits bullet 2.

Thus the Linux client currently leaves RDMA_MSGP disabled. The
Linux server handles RDMA_MSGP, but does not use any special
page flipping, so it confers no benefit.

Clean up the marshaling code by removing the logic that constructs
RDMA_MSGP type calls. This also reduces the maximum send iovec size
from four to just two elements.

/proc/sys/sunrpc/rdma_inline_write_padding is a kernel API, and
thus is left in place.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Devesh Sharma <devesh.sharma@avagotech.com>
net/sunrpc/xprtrdma/rpc_rdma.c
net/sunrpc/xprtrdma/verbs.c
net/sunrpc/xprtrdma/xprt_rdma.h