2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2003-2007 Network Appliance, Inc. All rights reserved.
|
|
|
|
*
|
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
* COPYING in the main directory of this source tree, or the BSD-type
|
|
|
|
* license below:
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* Redistributions in binary form must reproduce the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer in the documentation and/or other materials provided
|
|
|
|
* with the distribution.
|
|
|
|
*
|
|
|
|
* Neither the name of the Network Appliance, Inc. nor the names of
|
|
|
|
* its contributors may be used to endorse or promote products
|
|
|
|
* derived from this software without specific prior written
|
|
|
|
* permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _LINUX_SUNRPC_XPRT_RDMA_H
|
|
|
|
#define _LINUX_SUNRPC_XPRT_RDMA_H
|
|
|
|
|
|
|
|
#include <linux/wait.h> /* wait_queue_head_t, etc */
|
|
|
|
#include <linux/spinlock.h> /* spinlock_t, etc */
|
2011-07-27 07:09:06 +08:00
|
|
|
#include <linux/atomic.h> /* atomic_t, etc */
|
2014-05-28 22:32:17 +08:00
|
|
|
#include <linux/workqueue.h> /* struct work_struct */
|
2007-09-11 01:50:12 +08:00
|
|
|
|
|
|
|
#include <rdma/rdma_cm.h> /* RDMA connection api */
|
|
|
|
#include <rdma/ib_verbs.h> /* RDMA verbs api */
|
|
|
|
|
|
|
|
#include <linux/sunrpc/clnt.h> /* rpc_xprt */
|
|
|
|
#include <linux/sunrpc/rpc_rdma.h> /* RPC/RDMA protocol */
|
|
|
|
#include <linux/sunrpc/xprtrdma.h> /* xprt parameters */
|
|
|
|
|
2008-10-10 03:01:41 +08:00
|
|
|
#define RDMA_RESOLVE_TIMEOUT (5000) /* 5 seconds */
|
|
|
|
#define RDMA_CONNECT_RETRY_MAX (2) /* retries if no listener backlog */
|
|
|
|
|
2016-01-08 03:50:10 +08:00
|
|
|
#define RPCRDMA_BIND_TO (60U * HZ)
|
|
|
|
#define RPCRDMA_INIT_REEST_TO (5U * HZ)
|
|
|
|
#define RPCRDMA_MAX_REEST_TO (30U * HZ)
|
|
|
|
#define RPCRDMA_IDLE_DISC_TO (5U * 60 * HZ)
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* Interface Adapter -- one per transport instance
|
|
|
|
*/
|
|
|
|
struct rpcrdma_ia {
|
2015-03-31 02:34:21 +08:00
|
|
|
const struct rpcrdma_memreg_ops *ri_ops;
|
2015-05-26 23:51:56 +08:00
|
|
|
struct ib_device *ri_device;
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rdma_cm_id *ri_id;
|
|
|
|
struct ib_pd *ri_pd;
|
|
|
|
struct completion ri_done;
|
2017-04-12 01:23:10 +08:00
|
|
|
struct completion ri_remove_done;
|
2007-09-11 01:50:12 +08:00
|
|
|
int ri_async_rc;
|
2016-09-15 22:57:07 +08:00
|
|
|
unsigned int ri_max_segs;
|
2014-05-28 22:32:00 +08:00
|
|
|
unsigned int ri_max_frmr_depth;
|
2016-05-03 02:41:05 +08:00
|
|
|
unsigned int ri_max_inline_write;
|
|
|
|
unsigned int ri_max_inline_read;
|
2017-02-09 06:00:10 +08:00
|
|
|
unsigned int ri_max_send_sges;
|
2016-09-15 22:57:16 +08:00
|
|
|
bool ri_reminv_expected;
|
2017-02-09 05:59:54 +08:00
|
|
|
bool ri_implicit_roundup;
|
xprtrdma: Support for SG_GAP devices
Some devices (such as the Mellanox CX-4) can register, under a
single R_key, a set of memory regions that are not contiguous. When
this is done, all the segments in a Reply list, say, can then be
invalidated in a single LocalInv Work Request (or via Remote
Invalidation, which can invalidate exactly one R_key when completing
a Receive).
This means a single FastReg WR is used to register, and one or zero
LocalInv WRs can invalidate, the memory involved with RDMA transfers
on behalf of an RPC.
In addition, xprtrdma constructs some Reply chunks from three or
more segments. By registering them with SG_GAP, only one segment
is needed for the Reply chunk, allowing the whole chunk to be
invalidated remotely.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-11-29 23:52:24 +08:00
|
|
|
enum ib_mr_type ri_mrtype;
|
2017-04-12 01:23:10 +08:00
|
|
|
unsigned long ri_flags;
|
2015-01-22 00:03:35 +08:00
|
|
|
struct ib_qp_attr ri_qp_attr;
|
|
|
|
struct ib_qp_init_attr ri_qp_init_attr;
|
2007-09-11 01:50:12 +08:00
|
|
|
};
|
|
|
|
|
2017-04-12 01:23:10 +08:00
|
|
|
enum {
|
|
|
|
RPCRDMA_IAF_REMOVING = 0,
|
|
|
|
};
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* RDMA Endpoint -- one per transport instance
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct rpcrdma_ep {
|
|
|
|
atomic_t rep_cqcount;
|
|
|
|
int rep_cqinit;
|
|
|
|
int rep_connected;
|
|
|
|
struct ib_qp_init_attr rep_attr;
|
|
|
|
wait_queue_head_t rep_connect_wait;
|
2016-09-15 22:57:07 +08:00
|
|
|
struct rpcrdma_connect_private rep_cm_private;
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rdma_conn_param rep_remote_cma;
|
|
|
|
struct sockaddr_storage rep_remote_addr;
|
2014-05-28 22:32:17 +08:00
|
|
|
struct delayed_work rep_connect_worker;
|
2007-09-11 01:50:12 +08:00
|
|
|
};
|
|
|
|
|
2016-11-29 23:52:16 +08:00
|
|
|
static inline void
|
|
|
|
rpcrdma_init_cqcount(struct rpcrdma_ep *ep, int count)
|
|
|
|
{
|
|
|
|
atomic_set(&ep->rep_cqcount, ep->rep_cqinit - count);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* To update send queue accounting, provider must take a
|
|
|
|
* send completion every now and then.
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
rpcrdma_set_signaled(struct rpcrdma_ep *ep, struct ib_send_wr *send_wr)
|
|
|
|
{
|
|
|
|
send_wr->send_flags = 0;
|
|
|
|
if (unlikely(atomic_sub_return(1, &ep->rep_cqcount) <= 0)) {
|
|
|
|
rpcrdma_init_cqcount(ep, 0);
|
|
|
|
send_wr->send_flags = IB_SEND_SIGNALED;
|
|
|
|
}
|
|
|
|
}
|
2007-09-11 01:50:12 +08:00
|
|
|
|
2015-10-25 05:27:51 +08:00
|
|
|
/* Pre-allocate extra Work Requests for handling backward receives
|
|
|
|
* and sends. This is a fixed value because the Work Queues are
|
|
|
|
* allocated when the forward channel is set up.
|
|
|
|
*/
|
|
|
|
#if defined(CONFIG_SUNRPC_BACKCHANNEL)
|
|
|
|
#define RPCRDMA_BACKWARD_WRS (8)
|
|
|
|
#else
|
|
|
|
#define RPCRDMA_BACKWARD_WRS (0)
|
|
|
|
#endif
|
|
|
|
|
2015-01-22 00:04:00 +08:00
|
|
|
/* Registered buffer -- registered kmalloc'd memory for RDMA SEND/RECV
|
|
|
|
*
|
|
|
|
* The below structure appears at the front of a large region of kmalloc'd
|
|
|
|
* memory, which always starts on a good alignment boundary.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct rpcrdma_regbuf {
|
|
|
|
struct ib_sge rg_iov;
|
xprtrdma: Delay DMA mapping Send and Receive buffers
Currently, each regbuf is allocated and DMA mapped at the same time.
This is done during transport creation.
When a device driver is unloaded, every DMA-mapped buffer in use by
a transport has to be unmapped, and then remapped to the new
device if the driver is loaded again. Remapping will have to be done
_after_ the connect worker has set up the new device.
But there's an ordering problem:
call_allocate, which invokes xprt_rdma_allocate which calls
rpcrdma_alloc_regbuf to allocate Send buffers, happens _before_
the connect worker can run to set up the new device.
Instead, at transport creation, allocate each buffer, but leave it
unmapped. Once the RPC carries these buffers into ->send_request, by
which time a transport connection should have been established,
check to see that the RPC's buffers have been DMA mapped. If not,
map them there.
When device driver unplug support is added, it will simply unmap all
the transport's regbufs, but it doesn't have to deallocate the
underlying memory.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:56:18 +08:00
|
|
|
struct ib_device *rg_device;
|
2016-09-15 22:56:10 +08:00
|
|
|
enum dma_data_direction rg_direction;
|
2015-01-22 00:04:00 +08:00
|
|
|
__be32 rg_base[0] __attribute__ ((aligned(256)));
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline u64
|
|
|
|
rdmab_addr(struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
return rb->rg_iov.addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32
|
|
|
|
rdmab_length(struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
return rb->rg_iov.length;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u32
|
|
|
|
rdmab_lkey(struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
return rb->rg_iov.lkey;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct rpcrdma_msg *
|
|
|
|
rdmab_to_msg(struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
return (struct rpcrdma_msg *)rb->rg_base;
|
|
|
|
}
|
|
|
|
|
2017-04-12 01:23:02 +08:00
|
|
|
static inline struct ib_device *
|
|
|
|
rdmab_device(struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
return rb->rg_device;
|
|
|
|
}
|
|
|
|
|
2016-01-08 03:50:10 +08:00
|
|
|
#define RPCRDMA_DEF_GFP (GFP_NOIO | __GFP_NOWARN)
|
|
|
|
|
2016-05-03 02:40:56 +08:00
|
|
|
/* To ensure a transport can always make forward progress,
|
|
|
|
* the number of RDMA segments allowed in header chunk lists
|
|
|
|
* is capped at 8. This prevents less-capable devices and
|
|
|
|
* memory registrations from overrunning the Send buffer
|
|
|
|
* while building chunk lists.
|
|
|
|
*
|
|
|
|
* Elements of the Read list take up more room than the
|
|
|
|
* Write list or Reply chunk. 8 read segments means the Read
|
|
|
|
* list (or Write list or Reply chunk) cannot consume more
|
|
|
|
* than
|
|
|
|
*
|
|
|
|
* ((8 + 2) * read segment size) + 1 XDR words, or 244 bytes.
|
|
|
|
*
|
|
|
|
* And the fixed part of the header is another 24 bytes.
|
|
|
|
*
|
|
|
|
* The smallest inline threshold is 1024 bytes, ensuring that
|
|
|
|
* at least 750 bytes are available for RPC messages.
|
|
|
|
*/
|
2016-09-15 22:56:02 +08:00
|
|
|
enum {
|
|
|
|
RPCRDMA_MAX_HDR_SEGS = 8,
|
|
|
|
RPCRDMA_HDRBUF_SIZE = 256,
|
|
|
|
};
|
2016-05-03 02:40:56 +08:00
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* struct rpcrdma_rep -- this structure encapsulates state required to recv
|
|
|
|
* and complete a reply, asychronously. It needs several pieces of
|
|
|
|
* state:
|
|
|
|
* o recv buffer (posted to provider)
|
|
|
|
* o ib_sge (also donated to provider)
|
|
|
|
* o status of reply (length, success or not)
|
2016-06-30 01:54:25 +08:00
|
|
|
* o bookkeeping state to get run by reply handler (list, etc)
|
2007-09-11 01:50:12 +08:00
|
|
|
*
|
2016-06-30 01:54:25 +08:00
|
|
|
* These are allocated during initialization, per-transport instance.
|
2007-09-11 01:50:12 +08:00
|
|
|
*
|
|
|
|
* N of these are associated with a transport instance, and stored in
|
|
|
|
* struct rpcrdma_buffer. N is the max number of outstanding requests.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct rpcrdma_rep {
|
2016-03-05 00:28:36 +08:00
|
|
|
struct ib_cqe rr_cqe;
|
2016-09-15 22:57:16 +08:00
|
|
|
int rr_wc_flags;
|
|
|
|
u32 rr_inv_rkey;
|
2017-08-04 02:30:52 +08:00
|
|
|
struct rpcrdma_regbuf *rr_rdmabuf;
|
2015-05-26 23:51:37 +08:00
|
|
|
struct rpcrdma_xprt *rr_rxprt;
|
2015-10-25 05:27:10 +08:00
|
|
|
struct work_struct rr_work;
|
2017-08-04 02:30:03 +08:00
|
|
|
struct xdr_buf rr_hdrbuf;
|
|
|
|
struct xdr_stream rr_stream;
|
2015-01-22 00:04:25 +08:00
|
|
|
struct list_head rr_list;
|
2016-09-15 22:56:51 +08:00
|
|
|
struct ib_recv_wr rr_recv_wr;
|
2007-09-11 01:50:12 +08:00
|
|
|
};
|
|
|
|
|
2014-07-30 05:24:09 +08:00
|
|
|
/*
|
|
|
|
* struct rpcrdma_mw - external memory region metadata
|
|
|
|
*
|
|
|
|
* An external memory region is any buffer or page that is registered
|
|
|
|
* on the fly (ie, not pre-registered).
|
|
|
|
*
|
2014-07-30 05:24:28 +08:00
|
|
|
* Each rpcrdma_buffer has a list of free MWs anchored in rb_mws. During
|
2014-07-30 05:24:09 +08:00
|
|
|
* call_allocate, rpcrdma_buffer_get() assigns one to each segment in
|
|
|
|
* an rpcrdma_req. Then rpcrdma_register_external() grabs these to keep
|
|
|
|
* track of registration metadata while each RPC is pending.
|
|
|
|
* rpcrdma_deregister_external() uses this metadata to unmap and
|
|
|
|
* release these resources when an RPC is complete.
|
|
|
|
*/
|
|
|
|
enum rpcrdma_frmr_state {
|
|
|
|
FRMR_IS_INVALID, /* ready to be used */
|
|
|
|
FRMR_IS_VALID, /* in use */
|
2016-11-08 05:16:24 +08:00
|
|
|
FRMR_FLUSHED_FR, /* flushed FASTREG WR */
|
|
|
|
FRMR_FLUSHED_LI, /* flushed LOCALINV WR */
|
2014-07-30 05:24:09 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct rpcrdma_frmr {
|
|
|
|
struct ib_mr *fr_mr;
|
2016-03-05 00:28:53 +08:00
|
|
|
struct ib_cqe fr_cqe;
|
2014-07-30 05:24:09 +08:00
|
|
|
enum rpcrdma_frmr_state fr_state;
|
2016-03-05 00:28:53 +08:00
|
|
|
struct completion fr_linv_done;
|
2015-12-17 06:22:31 +08:00
|
|
|
union {
|
|
|
|
struct ib_reg_wr fr_regwr;
|
|
|
|
struct ib_send_wr fr_invwr;
|
|
|
|
};
|
2014-07-30 05:24:09 +08:00
|
|
|
};
|
|
|
|
|
2015-05-26 23:53:23 +08:00
|
|
|
struct rpcrdma_fmr {
|
2016-06-30 01:52:37 +08:00
|
|
|
struct ib_fmr *fm_mr;
|
|
|
|
u64 *fm_physaddrs;
|
2014-07-30 05:24:09 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct rpcrdma_mw {
|
2016-06-30 01:52:21 +08:00
|
|
|
struct list_head mw_list;
|
|
|
|
struct scatterlist *mw_sg;
|
|
|
|
int mw_nents;
|
|
|
|
enum dma_data_direction mw_dir;
|
2017-06-08 23:51:56 +08:00
|
|
|
unsigned long mw_flags;
|
2014-07-30 05:24:09 +08:00
|
|
|
union {
|
2015-05-26 23:53:23 +08:00
|
|
|
struct rpcrdma_fmr fmr;
|
2014-07-30 05:24:09 +08:00
|
|
|
struct rpcrdma_frmr frmr;
|
2016-03-05 00:28:45 +08:00
|
|
|
};
|
2016-05-03 02:42:29 +08:00
|
|
|
struct rpcrdma_xprt *mw_xprt;
|
2016-06-30 01:54:16 +08:00
|
|
|
u32 mw_handle;
|
|
|
|
u32 mw_length;
|
|
|
|
u64 mw_offset;
|
2014-07-30 05:24:28 +08:00
|
|
|
struct list_head mw_all;
|
2014-07-30 05:24:09 +08:00
|
|
|
};
|
|
|
|
|
2017-06-08 23:51:56 +08:00
|
|
|
/* mw_flags */
|
|
|
|
enum {
|
|
|
|
RPCRDMA_MW_F_RI = 1,
|
|
|
|
};
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* struct rpcrdma_req -- structure central to the request/reply sequence.
|
|
|
|
*
|
|
|
|
* N of these are associated with a transport instance, and stored in
|
|
|
|
* struct rpcrdma_buffer. N is the max number of outstanding requests.
|
|
|
|
*
|
|
|
|
* It includes pre-registered buffer memory for send AND recv.
|
|
|
|
* The recv buffer, however, is not owned by this structure, and
|
|
|
|
* is "donated" to the hardware when a recv is posted. When a
|
|
|
|
* reply is handled, the recv buffer used is given back to the
|
|
|
|
* struct rpcrdma_req associated with the request.
|
|
|
|
*
|
|
|
|
* In addition to the basic memory, this structure includes an array
|
|
|
|
* of iovs for send operations. The reason is that the iovs passed to
|
|
|
|
* ib_post_{send,recv} must not be modified until the work request
|
|
|
|
* completes.
|
|
|
|
*/
|
|
|
|
|
2016-06-30 01:54:25 +08:00
|
|
|
/* Maximum number of page-sized "segments" per chunk list to be
|
|
|
|
* registered or invalidated. Must handle a Reply chunk:
|
|
|
|
*/
|
|
|
|
enum {
|
|
|
|
RPCRDMA_MAX_IOV_SEGS = 3,
|
|
|
|
RPCRDMA_MAX_DATA_SEGS = ((1 * 1024 * 1024) / PAGE_SIZE) + 1,
|
|
|
|
RPCRDMA_MAX_SEGS = RPCRDMA_MAX_DATA_SEGS +
|
|
|
|
RPCRDMA_MAX_IOV_SEGS,
|
|
|
|
};
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rpcrdma_mr_seg { /* chunk descriptors */
|
|
|
|
u32 mr_len; /* length of chunk or segment */
|
|
|
|
struct page *mr_page; /* owning page, if any */
|
|
|
|
char *mr_offset; /* kva if no page, else offset */
|
|
|
|
};
|
|
|
|
|
2017-02-09 06:00:18 +08:00
|
|
|
/* The Send SGE array is provisioned to send a maximum size
|
|
|
|
* inline request:
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
* - RPC-over-RDMA header
|
|
|
|
* - xdr_buf head iovec
|
2017-02-09 06:00:18 +08:00
|
|
|
* - RPCRDMA_MAX_INLINE bytes, in pages
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
* - xdr_buf tail iovec
|
2017-02-09 06:00:18 +08:00
|
|
|
*
|
|
|
|
* The actual number of array elements consumed by each RPC
|
|
|
|
* depends on the device's max_sge limit.
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
*/
|
|
|
|
enum {
|
2017-02-09 06:00:10 +08:00
|
|
|
RPCRDMA_MIN_SEND_SGES = 3,
|
2017-02-09 06:00:18 +08:00
|
|
|
RPCRDMA_MAX_PAGE_SGES = RPCRDMA_MAX_INLINE >> PAGE_SHIFT,
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
RPCRDMA_MAX_SEND_SGES = 1 + 1 + RPCRDMA_MAX_PAGE_SGES + 1,
|
|
|
|
};
|
2015-08-04 01:03:39 +08:00
|
|
|
|
2016-06-30 01:54:25 +08:00
|
|
|
struct rpcrdma_buffer;
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rpcrdma_req {
|
2017-06-08 23:52:12 +08:00
|
|
|
struct list_head rl_list;
|
xprtrdma: Fix client lock-up after application signal fires
After a signal, the RPC client aborts synchronous RPCs running on
behalf of the signaled application.
The server is still executing those RPCs, and will write the results
back into the client's memory when it's done. By the time the server
writes the results, that memory is likely being used for other
purposes. Therefore xprtrdma has to immediately invalidate all
memory regions used by those aborted RPCs to prevent the server's
writes from clobbering that re-used memory.
With FMR memory registration, invalidation takes a relatively long
time. In fact, the invalidation is often still running when the
server tries to write the results into the memory regions that are
being invalidated.
This sets up a race between two processes:
1. After the signal, xprt_rdma_free calls ro_unmap_safe.
2. While ro_unmap_safe is still running, the server replies and
rpcrdma_reply_handler runs, calling ro_unmap_sync.
Both processes invoke ib_unmap_fmr on the same FMR.
The mlx4 driver allows two ib_unmap_fmr calls on the same FMR at
the same time, but HCAs generally don't tolerate this. Sometimes
this can result in a system crash.
If the HCA happens to survive, rpcrdma_reply_handler continues. It
removes the rpc_rqst from rq_list and releases the transport_lock.
This enables xprt_rdma_free to run in another process, and the
rpc_rqst is released while rpcrdma_reply_handler is still waiting
for the ib_unmap_fmr call to finish.
But further down in rpcrdma_reply_handler, the transport_lock is
taken again, and "rqst" is dereferenced. If "rqst" has already been
released, this triggers a general protection fault. Since bottom-
halves are disabled, the system locks up.
Address both issues by reversing the order of the xprt_lookup_rqst
call and the ro_unmap_sync call. Introduce a separate lookup
mechanism for rpcrdma_req's to enable calling ro_unmap_sync before
xprt_lookup_rqst. Now the handler takes the transport_lock once
and holds it for the XID lookup and RPC completion.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=305
Fixes: 68791649a725 ('xprtrdma: Invalidate in the RPC reply ... ')
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-06-08 23:52:20 +08:00
|
|
|
__be32 rl_xid;
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
unsigned int rl_mapped_sges;
|
2015-08-04 01:03:39 +08:00
|
|
|
unsigned int rl_connect_cookie;
|
|
|
|
struct rpcrdma_buffer *rl_buffer;
|
2016-09-15 22:56:43 +08:00
|
|
|
struct rpcrdma_rep *rl_reply;
|
2017-08-11 00:47:28 +08:00
|
|
|
struct xdr_stream rl_stream;
|
|
|
|
struct xdr_buf rl_hdrbuf;
|
2016-09-15 22:56:43 +08:00
|
|
|
struct ib_send_wr rl_send_wr;
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
struct ib_sge rl_send_sge[RPCRDMA_MAX_SEND_SGES];
|
xprtrdma: Initialize separate RPC call and reply buffers
RPC-over-RDMA needs to separate its RPC call and reply buffers.
o When an RPC Call is sent, rq_snd_buf is DMA mapped for an RDMA
Send operation using DMA_TO_DEVICE
o If the client expects a large RPC reply, it DMA maps rq_rcv_buf
as part of a Reply chunk using DMA_FROM_DEVICE
The two mappings are for data movement in opposite directions.
DMA-API.txt suggests that if these mappings share a DMA cacheline,
bad things can happen. This could occur in the final bytes of
rq_snd_buf and the first bytes of rq_rcv_buf if the two buffers
happen to share a DMA cacheline.
On x86_64 the cacheline size is typically 8 bytes, and RPC call
messages are usually much smaller than the send buffer, so this
hasn't been a noticeable problem. But the DMA cacheline size can be
larger on other platforms.
Also, often rq_rcv_buf starts most of the way into a page, thus
an additional RDMA segment is needed to map and register the end of
that buffer. Try to avoid that scenario to reduce the cost of
registering and invalidating Reply chunks.
Instead of carrying a single regbuf that covers both rq_snd_buf and
rq_rcv_buf, each struct rpcrdma_req now carries one regbuf for
rq_snd_buf and one regbuf for rq_rcv_buf.
Some incidental changes worth noting:
- To clear out some spaghetti, refactor xprt_rdma_allocate.
- The value stored in rg_size is the same as the value stored in
the iov.length field, so eliminate rg_size
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:55:53 +08:00
|
|
|
struct rpcrdma_regbuf *rl_rdmabuf; /* xprt header */
|
|
|
|
struct rpcrdma_regbuf *rl_sendbuf; /* rq_snd_buf */
|
|
|
|
struct rpcrdma_regbuf *rl_recvbuf; /* rq_rcv_buf */
|
2015-10-25 05:27:43 +08:00
|
|
|
|
2016-03-05 00:28:53 +08:00
|
|
|
struct ib_cqe rl_cqe;
|
2015-10-25 05:27:43 +08:00
|
|
|
struct list_head rl_all;
|
|
|
|
bool rl_backchannel;
|
2016-06-30 01:54:25 +08:00
|
|
|
|
|
|
|
struct list_head rl_registered; /* registered segments */
|
|
|
|
struct rpcrdma_mr_seg rl_segments[RPCRDMA_MAX_SEGS];
|
2007-09-11 01:50:12 +08:00
|
|
|
};
|
2015-01-22 00:04:08 +08:00
|
|
|
|
2016-09-15 22:55:45 +08:00
|
|
|
static inline void
|
|
|
|
rpcrdma_set_xprtdata(struct rpc_rqst *rqst, struct rpcrdma_req *req)
|
|
|
|
{
|
|
|
|
rqst->rq_xprtdata = req;
|
|
|
|
}
|
|
|
|
|
2015-01-22 00:04:08 +08:00
|
|
|
static inline struct rpcrdma_req *
|
|
|
|
rpcr_to_rdmar(struct rpc_rqst *rqst)
|
|
|
|
{
|
2016-09-15 22:55:45 +08:00
|
|
|
return rqst->rq_xprtdata;
|
2015-01-22 00:04:08 +08:00
|
|
|
}
|
2007-09-11 01:50:12 +08:00
|
|
|
|
2017-02-09 06:00:43 +08:00
|
|
|
static inline void
|
|
|
|
rpcrdma_push_mw(struct rpcrdma_mw *mw, struct list_head *list)
|
|
|
|
{
|
|
|
|
list_add_tail(&mw->mw_list, list);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct rpcrdma_mw *
|
|
|
|
rpcrdma_pop_mw(struct list_head *list)
|
|
|
|
{
|
|
|
|
struct rpcrdma_mw *mw;
|
|
|
|
|
|
|
|
mw = list_first_entry(list, struct rpcrdma_mw, mw_list);
|
|
|
|
list_del(&mw->mw_list);
|
|
|
|
return mw;
|
|
|
|
}
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* struct rpcrdma_buffer -- holds list/queue of pre-registered memory for
|
|
|
|
* inline requests/replies, and client/server credits.
|
|
|
|
*
|
|
|
|
* One of these is associated with a transport instance
|
|
|
|
*/
|
|
|
|
struct rpcrdma_buffer {
|
2015-05-26 23:53:13 +08:00
|
|
|
spinlock_t rb_mwlock; /* protect rb_mws list */
|
|
|
|
struct list_head rb_mws;
|
|
|
|
struct list_head rb_all;
|
|
|
|
|
2015-10-25 05:27:02 +08:00
|
|
|
spinlock_t rb_lock; /* protect buf lists */
|
xprtrdma: Fix receive buffer accounting
An RPC can terminate before its reply arrives, if a credential
problem or a soft timeout occurs. After this happens, xprtrdma
reports it is out of Receive buffers.
A Receive buffer is posted before each RPC is sent, and returned to
the buffer pool when a reply is received. If no reply is received
for an RPC, that Receive buffer remains posted. But xprtrdma tries
to post another when the next RPC is sent.
If this happens a few dozen times, there are no receive buffers left
to be posted at send time. I don't see a way for a transport
connection to recover at that point, and it will spit warnings and
unnecessarily delay RPCs on occasion for its remaining lifetime.
Commit 1e465fd4ff47 ("xprtrdma: Replace send and receive arrays")
removed a little bit of logic to detect this case and not provide
a Receive buffer so no more buffers are posted, and then transport
operation continues correctly. We didn't understand what that logic
did, and it wasn't commented, so it was removed as part of the
overhaul to support backchannel requests.
Restore it, but be wary of the need to keep extra Receives posted
to deal with backchannel requests.
Fixes: 1e465fd4ff47 ("xprtrdma: Replace send and receive arrays")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2016-09-06 23:22:58 +08:00
|
|
|
int rb_send_count, rb_recv_count;
|
2015-10-25 05:27:02 +08:00
|
|
|
struct list_head rb_send_bufs;
|
|
|
|
struct list_head rb_recv_bufs;
|
xprtrdma: Fix client lock-up after application signal fires
After a signal, the RPC client aborts synchronous RPCs running on
behalf of the signaled application.
The server is still executing those RPCs, and will write the results
back into the client's memory when it's done. By the time the server
writes the results, that memory is likely being used for other
purposes. Therefore xprtrdma has to immediately invalidate all
memory regions used by those aborted RPCs to prevent the server's
writes from clobbering that re-used memory.
With FMR memory registration, invalidation takes a relatively long
time. In fact, the invalidation is often still running when the
server tries to write the results into the memory regions that are
being invalidated.
This sets up a race between two processes:
1. After the signal, xprt_rdma_free calls ro_unmap_safe.
2. While ro_unmap_safe is still running, the server replies and
rpcrdma_reply_handler runs, calling ro_unmap_sync.
Both processes invoke ib_unmap_fmr on the same FMR.
The mlx4 driver allows two ib_unmap_fmr calls on the same FMR at
the same time, but HCAs generally don't tolerate this. Sometimes
this can result in a system crash.
If the HCA happens to survive, rpcrdma_reply_handler continues. It
removes the rpc_rqst from rq_list and releases the transport_lock.
This enables xprt_rdma_free to run in another process, and the
rpc_rqst is released while rpcrdma_reply_handler is still waiting
for the ib_unmap_fmr call to finish.
But further down in rpcrdma_reply_handler, the transport_lock is
taken again, and "rqst" is dereferenced. If "rqst" has already been
released, this triggers a general protection fault. Since bottom-
halves are disabled, the system locks up.
Address both issues by reversing the order of the xprt_lookup_rqst
call and the ro_unmap_sync call. Introduce a separate lookup
mechanism for rpcrdma_req's to enable calling ro_unmap_sync before
xprt_lookup_rqst. Now the handler takes the transport_lock once
and holds it for the XID lookup and RPC completion.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=305
Fixes: 68791649a725 ('xprtrdma: Invalidate in the RPC reply ... ')
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-06-08 23:52:20 +08:00
|
|
|
struct list_head rb_pending;
|
2015-05-26 23:53:13 +08:00
|
|
|
u32 rb_max_requests;
|
2016-03-05 00:28:27 +08:00
|
|
|
atomic_t rb_credits; /* most recent credit grant */
|
2015-10-25 05:27:43 +08:00
|
|
|
|
|
|
|
u32 rb_bc_srv_max_requests;
|
|
|
|
spinlock_t rb_reqslock; /* protect rb_allreqs */
|
|
|
|
struct list_head rb_allreqs;
|
2016-01-08 03:50:10 +08:00
|
|
|
|
|
|
|
u32 rb_bc_max_requests;
|
2016-06-30 01:52:54 +08:00
|
|
|
|
|
|
|
spinlock_t rb_recovery_lock; /* protect rb_stale_mrs */
|
|
|
|
struct list_head rb_stale_mrs;
|
|
|
|
struct delayed_work rb_recovery_worker;
|
2016-06-30 01:54:00 +08:00
|
|
|
struct delayed_work rb_refresh_worker;
|
2007-09-11 01:50:12 +08:00
|
|
|
};
|
|
|
|
#define rdmab_to_ia(b) (&container_of((b), struct rpcrdma_xprt, rx_buf)->rx_ia)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal structure for transport instance creation. This
|
|
|
|
* exists primarily for modularity.
|
|
|
|
*
|
|
|
|
* This data should be set with mount options
|
|
|
|
*/
|
|
|
|
struct rpcrdma_create_data_internal {
|
|
|
|
struct sockaddr_storage addr; /* RDMA server address */
|
|
|
|
unsigned int max_requests; /* max requests (slots) in flight */
|
|
|
|
unsigned int rsize; /* mount rsize - max read hdr+data */
|
|
|
|
unsigned int wsize; /* mount wsize - max write hdr+data */
|
|
|
|
unsigned int inline_rsize; /* max non-rdma read data payload */
|
|
|
|
unsigned int inline_wsize; /* max non-rdma write data payload */
|
|
|
|
unsigned int padding; /* non-rdma write header padding */
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Statistics for RPCRDMA
|
|
|
|
*/
|
|
|
|
struct rpcrdma_stats {
|
|
|
|
unsigned long read_chunk_count;
|
|
|
|
unsigned long write_chunk_count;
|
|
|
|
unsigned long reply_chunk_count;
|
|
|
|
|
|
|
|
unsigned long long total_rdma_request;
|
|
|
|
unsigned long long total_rdma_reply;
|
|
|
|
|
|
|
|
unsigned long long pullup_copy_count;
|
|
|
|
unsigned long long fixup_copy_count;
|
|
|
|
unsigned long hardway_register_count;
|
|
|
|
unsigned long failed_marshal_count;
|
|
|
|
unsigned long bad_reply_count;
|
2015-08-04 01:04:45 +08:00
|
|
|
unsigned long nomsg_call_count;
|
2015-10-25 05:28:08 +08:00
|
|
|
unsigned long bcall_count;
|
2016-06-30 01:52:54 +08:00
|
|
|
unsigned long mrs_recovered;
|
|
|
|
unsigned long mrs_orphaned;
|
2016-06-30 01:54:00 +08:00
|
|
|
unsigned long mrs_allocated;
|
2016-09-15 22:57:16 +08:00
|
|
|
unsigned long local_inv_needed;
|
2007-09-11 01:50:12 +08:00
|
|
|
};
|
|
|
|
|
2015-03-31 02:34:21 +08:00
|
|
|
/*
|
|
|
|
* Per-registration mode operations
|
|
|
|
*/
|
2015-03-31 02:34:30 +08:00
|
|
|
struct rpcrdma_xprt;
|
2015-03-31 02:34:21 +08:00
|
|
|
struct rpcrdma_memreg_ops {
|
2015-03-31 02:34:39 +08:00
|
|
|
int (*ro_map)(struct rpcrdma_xprt *,
|
2016-06-30 01:54:16 +08:00
|
|
|
struct rpcrdma_mr_seg *, int, bool,
|
|
|
|
struct rpcrdma_mw **);
|
2015-12-17 06:22:39 +08:00
|
|
|
void (*ro_unmap_sync)(struct rpcrdma_xprt *,
|
2017-06-08 23:52:04 +08:00
|
|
|
struct list_head *);
|
2016-05-03 02:42:46 +08:00
|
|
|
void (*ro_unmap_safe)(struct rpcrdma_xprt *,
|
|
|
|
struct rpcrdma_req *, bool);
|
2016-06-30 01:52:54 +08:00
|
|
|
void (*ro_recover_mr)(struct rpcrdma_mw *);
|
2015-03-31 02:35:26 +08:00
|
|
|
int (*ro_open)(struct rpcrdma_ia *,
|
|
|
|
struct rpcrdma_ep *,
|
|
|
|
struct rpcrdma_create_data_internal *);
|
2015-03-31 02:34:30 +08:00
|
|
|
size_t (*ro_maxpages)(struct rpcrdma_xprt *);
|
2016-06-30 01:54:00 +08:00
|
|
|
int (*ro_init_mr)(struct rpcrdma_ia *,
|
|
|
|
struct rpcrdma_mw *);
|
|
|
|
void (*ro_release_mr)(struct rpcrdma_mw *);
|
2015-03-31 02:34:21 +08:00
|
|
|
const char *ro_displayname;
|
2016-09-15 22:57:16 +08:00
|
|
|
const int ro_send_w_inv_ok;
|
2015-03-31 02:34:21 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
extern const struct rpcrdma_memreg_ops rpcrdma_fmr_memreg_ops;
|
|
|
|
extern const struct rpcrdma_memreg_ops rpcrdma_frwr_memreg_ops;
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* RPCRDMA transport -- encapsulates the structures above for
|
|
|
|
* integration with RPC.
|
|
|
|
*
|
|
|
|
* The contained structures are embedded, not pointers,
|
|
|
|
* for convenience. This structure need not be visible externally.
|
|
|
|
*
|
|
|
|
* It is allocated and initialized during mount, and released
|
|
|
|
* during unmount.
|
|
|
|
*/
|
|
|
|
struct rpcrdma_xprt {
|
2015-01-22 00:02:37 +08:00
|
|
|
struct rpc_xprt rx_xprt;
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rpcrdma_ia rx_ia;
|
|
|
|
struct rpcrdma_ep rx_ep;
|
|
|
|
struct rpcrdma_buffer rx_buf;
|
|
|
|
struct rpcrdma_create_data_internal rx_data;
|
2015-01-22 00:02:37 +08:00
|
|
|
struct delayed_work rx_connect_worker;
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rpcrdma_stats rx_stats;
|
|
|
|
};
|
|
|
|
|
2015-01-22 00:02:37 +08:00
|
|
|
#define rpcx_to_rdmax(x) container_of(x, struct rpcrdma_xprt, rx_xprt)
|
2007-09-11 01:50:12 +08:00
|
|
|
#define rpcx_to_rdmad(x) (rpcx_to_rdmax(x)->rx_data)
|
|
|
|
|
2008-10-10 03:01:11 +08:00
|
|
|
/* Setting this to 0 ensures interoperability with early servers.
|
|
|
|
* Setting this to 1 enhances certain unaligned read/write performance.
|
|
|
|
* Default is 0, see sysctl entry and rpc_rdma.c rpcrdma_convert_iovs() */
|
|
|
|
extern int xprt_rdma_pad_optimize;
|
|
|
|
|
2017-04-12 01:22:54 +08:00
|
|
|
/* This setting controls the hunt for a supported memory
|
|
|
|
* registration strategy.
|
|
|
|
*/
|
|
|
|
extern unsigned int xprt_rdma_memreg_strategy;
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* Interface Adapter calls - xprtrdma/verbs.c
|
|
|
|
*/
|
2017-04-12 01:22:54 +08:00
|
|
|
int rpcrdma_ia_open(struct rpcrdma_xprt *xprt, struct sockaddr *addr);
|
2017-04-12 01:23:10 +08:00
|
|
|
void rpcrdma_ia_remove(struct rpcrdma_ia *ia);
|
2007-09-11 01:50:12 +08:00
|
|
|
void rpcrdma_ia_close(struct rpcrdma_ia *);
|
2016-06-30 01:53:27 +08:00
|
|
|
bool frwr_is_supported(struct rpcrdma_ia *);
|
|
|
|
bool fmr_is_supported(struct rpcrdma_ia *);
|
2007-09-11 01:50:12 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Endpoint calls - xprtrdma/verbs.c
|
|
|
|
*/
|
|
|
|
int rpcrdma_ep_create(struct rpcrdma_ep *, struct rpcrdma_ia *,
|
|
|
|
struct rpcrdma_create_data_internal *);
|
2014-05-28 22:33:16 +08:00
|
|
|
void rpcrdma_ep_destroy(struct rpcrdma_ep *, struct rpcrdma_ia *);
|
2007-09-11 01:50:12 +08:00
|
|
|
int rpcrdma_ep_connect(struct rpcrdma_ep *, struct rpcrdma_ia *);
|
2016-11-29 23:53:37 +08:00
|
|
|
void rpcrdma_conn_func(struct rpcrdma_ep *ep);
|
2014-07-30 05:25:55 +08:00
|
|
|
void rpcrdma_ep_disconnect(struct rpcrdma_ep *, struct rpcrdma_ia *);
|
2007-09-11 01:50:12 +08:00
|
|
|
|
|
|
|
int rpcrdma_ep_post(struct rpcrdma_ia *, struct rpcrdma_ep *,
|
|
|
|
struct rpcrdma_req *);
|
2016-09-15 22:56:35 +08:00
|
|
|
int rpcrdma_ep_post_recv(struct rpcrdma_ia *, struct rpcrdma_rep *);
|
2007-09-11 01:50:12 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Buffer calls - xprtrdma/verbs.c
|
|
|
|
*/
|
2015-10-25 05:27:43 +08:00
|
|
|
struct rpcrdma_req *rpcrdma_create_req(struct rpcrdma_xprt *);
|
|
|
|
struct rpcrdma_rep *rpcrdma_create_rep(struct rpcrdma_xprt *);
|
2016-09-15 22:56:26 +08:00
|
|
|
void rpcrdma_destroy_req(struct rpcrdma_req *);
|
2015-01-22 00:03:44 +08:00
|
|
|
int rpcrdma_buffer_create(struct rpcrdma_xprt *);
|
2007-09-11 01:50:12 +08:00
|
|
|
void rpcrdma_buffer_destroy(struct rpcrdma_buffer *);
|
|
|
|
|
xprtrdma: Fix client lock-up after application signal fires
After a signal, the RPC client aborts synchronous RPCs running on
behalf of the signaled application.
The server is still executing those RPCs, and will write the results
back into the client's memory when it's done. By the time the server
writes the results, that memory is likely being used for other
purposes. Therefore xprtrdma has to immediately invalidate all
memory regions used by those aborted RPCs to prevent the server's
writes from clobbering that re-used memory.
With FMR memory registration, invalidation takes a relatively long
time. In fact, the invalidation is often still running when the
server tries to write the results into the memory regions that are
being invalidated.
This sets up a race between two processes:
1. After the signal, xprt_rdma_free calls ro_unmap_safe.
2. While ro_unmap_safe is still running, the server replies and
rpcrdma_reply_handler runs, calling ro_unmap_sync.
Both processes invoke ib_unmap_fmr on the same FMR.
The mlx4 driver allows two ib_unmap_fmr calls on the same FMR at
the same time, but HCAs generally don't tolerate this. Sometimes
this can result in a system crash.
If the HCA happens to survive, rpcrdma_reply_handler continues. It
removes the rpc_rqst from rq_list and releases the transport_lock.
This enables xprt_rdma_free to run in another process, and the
rpc_rqst is released while rpcrdma_reply_handler is still waiting
for the ib_unmap_fmr call to finish.
But further down in rpcrdma_reply_handler, the transport_lock is
taken again, and "rqst" is dereferenced. If "rqst" has already been
released, this triggers a general protection fault. Since bottom-
halves are disabled, the system locks up.
Address both issues by reversing the order of the xprt_lookup_rqst
call and the ro_unmap_sync call. Introduce a separate lookup
mechanism for rpcrdma_req's to enable calling ro_unmap_sync before
xprt_lookup_rqst. Now the handler takes the transport_lock once
and holds it for the XID lookup and RPC completion.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=305
Fixes: 68791649a725 ('xprtrdma: Invalidate in the RPC reply ... ')
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-06-08 23:52:20 +08:00
|
|
|
static inline void
|
|
|
|
rpcrdma_insert_req(struct rpcrdma_buffer *buffers, struct rpcrdma_req *req)
|
|
|
|
{
|
|
|
|
spin_lock(&buffers->rb_lock);
|
|
|
|
if (list_empty(&req->rl_list))
|
|
|
|
list_add_tail(&req->rl_list, &buffers->rb_pending);
|
|
|
|
spin_unlock(&buffers->rb_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct rpcrdma_req *
|
|
|
|
rpcrdma_lookup_req_locked(struct rpcrdma_buffer *buffers, __be32 xid)
|
|
|
|
{
|
|
|
|
struct rpcrdma_req *pos;
|
|
|
|
|
|
|
|
list_for_each_entry(pos, &buffers->rb_pending, rl_list)
|
|
|
|
if (pos->rl_xid == xid)
|
|
|
|
return pos;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
rpcrdma_remove_req(struct rpcrdma_buffer *buffers, struct rpcrdma_req *req)
|
|
|
|
{
|
|
|
|
spin_lock(&buffers->rb_lock);
|
|
|
|
list_del(&req->rl_list);
|
|
|
|
spin_unlock(&buffers->rb_lock);
|
|
|
|
}
|
|
|
|
|
2015-05-26 23:52:06 +08:00
|
|
|
struct rpcrdma_mw *rpcrdma_get_mw(struct rpcrdma_xprt *);
|
|
|
|
void rpcrdma_put_mw(struct rpcrdma_xprt *, struct rpcrdma_mw *);
|
2007-09-11 01:50:12 +08:00
|
|
|
struct rpcrdma_req *rpcrdma_buffer_get(struct rpcrdma_buffer *);
|
|
|
|
void rpcrdma_buffer_put(struct rpcrdma_req *);
|
|
|
|
void rpcrdma_recv_buffer_get(struct rpcrdma_req *);
|
|
|
|
void rpcrdma_recv_buffer_put(struct rpcrdma_rep *);
|
|
|
|
|
2016-06-30 01:52:54 +08:00
|
|
|
void rpcrdma_defer_mr_recovery(struct rpcrdma_mw *);
|
|
|
|
|
2016-09-15 22:56:26 +08:00
|
|
|
struct rpcrdma_regbuf *rpcrdma_alloc_regbuf(size_t, enum dma_data_direction,
|
2016-09-15 22:56:10 +08:00
|
|
|
gfp_t);
|
xprtrdma: Delay DMA mapping Send and Receive buffers
Currently, each regbuf is allocated and DMA mapped at the same time.
This is done during transport creation.
When a device driver is unloaded, every DMA-mapped buffer in use by
a transport has to be unmapped, and then remapped to the new
device if the driver is loaded again. Remapping will have to be done
_after_ the connect worker has set up the new device.
But there's an ordering problem:
call_allocate, which invokes xprt_rdma_allocate which calls
rpcrdma_alloc_regbuf to allocate Send buffers, happens _before_
the connect worker can run to set up the new device.
Instead, at transport creation, allocate each buffer, but leave it
unmapped. Once the RPC carries these buffers into ->send_request, by
which time a transport connection should have been established,
check to see that the RPC's buffers have been DMA mapped. If not,
map them there.
When device driver unplug support is added, it will simply unmap all
the transport's regbufs, but it doesn't have to deallocate the
underlying memory.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:56:18 +08:00
|
|
|
bool __rpcrdma_dma_map_regbuf(struct rpcrdma_ia *, struct rpcrdma_regbuf *);
|
2016-09-15 22:56:26 +08:00
|
|
|
void rpcrdma_free_regbuf(struct rpcrdma_regbuf *);
|
2015-01-22 00:04:00 +08:00
|
|
|
|
xprtrdma: Delay DMA mapping Send and Receive buffers
Currently, each regbuf is allocated and DMA mapped at the same time.
This is done during transport creation.
When a device driver is unloaded, every DMA-mapped buffer in use by
a transport has to be unmapped, and then remapped to the new
device if the driver is loaded again. Remapping will have to be done
_after_ the connect worker has set up the new device.
But there's an ordering problem:
call_allocate, which invokes xprt_rdma_allocate which calls
rpcrdma_alloc_regbuf to allocate Send buffers, happens _before_
the connect worker can run to set up the new device.
Instead, at transport creation, allocate each buffer, but leave it
unmapped. Once the RPC carries these buffers into ->send_request, by
which time a transport connection should have been established,
check to see that the RPC's buffers have been DMA mapped. If not,
map them there.
When device driver unplug support is added, it will simply unmap all
the transport's regbufs, but it doesn't have to deallocate the
underlying memory.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:56:18 +08:00
|
|
|
static inline bool
|
|
|
|
rpcrdma_regbuf_is_mapped(struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
return rb->rg_device != NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
rpcrdma_dma_map_regbuf(struct rpcrdma_ia *ia, struct rpcrdma_regbuf *rb)
|
|
|
|
{
|
|
|
|
if (likely(rpcrdma_regbuf_is_mapped(rb)))
|
|
|
|
return true;
|
|
|
|
return __rpcrdma_dma_map_regbuf(ia, rb);
|
|
|
|
}
|
|
|
|
|
2015-10-25 05:27:43 +08:00
|
|
|
int rpcrdma_ep_post_extra_recv(struct rpcrdma_xprt *, unsigned int);
|
2015-03-31 02:35:44 +08:00
|
|
|
|
2015-10-25 05:27:10 +08:00
|
|
|
int rpcrdma_alloc_wq(void);
|
|
|
|
void rpcrdma_destroy_wq(void);
|
|
|
|
|
2015-03-31 02:35:44 +08:00
|
|
|
/*
|
|
|
|
* Wrappers for chunk registration, shared by read/write chunk code.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline enum dma_data_direction
|
|
|
|
rpcrdma_data_dir(bool writing)
|
|
|
|
{
|
|
|
|
return writing ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
|
|
|
|
}
|
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
|
|
|
* RPC/RDMA protocol calls - xprtrdma/rpc_rdma.c
|
|
|
|
*/
|
xprtrdma: Use gathered Send for large inline messages
An RPC Call message that is sent inline but that has a data payload
(ie, one or more items in rq_snd_buf's page list) must be "pulled
up:"
- call_allocate has to reserve enough RPC Call buffer space to
accommodate the data payload
- call_transmit has to memcopy the rq_snd_buf's page list and tail
into its head iovec before it is sent
As the inline threshold is increased beyond its current 1KB default,
however, this means data payloads of more than a few KB are copied
by the host CPU. For example, if the inline threshold is increased
just to 4KB, then NFS WRITE requests up to 4KB would involve a
memcpy of the NFS WRITE's payload data into the RPC Call buffer.
This is an undesirable amount of participation by the host CPU.
The inline threshold may be much larger than 4KB in the future,
after negotiation with a peer server.
Instead of copying the components of rq_snd_buf into its head iovec,
construct a gather list of these components, and send them all in
place. The same approach is already used in the Linux server's
RPC-over-RDMA reply path.
This mechanism also eliminates the need for rpcrdma_tail_pullup,
which is used to manage the XDR pad and trailing inline content when
a Read list is present.
This requires that the pages in rq_snd_buf's page list be DMA-mapped
during marshaling, and unmapped when a data-bearing RPC is
completed. This is slightly less efficient for very small I/O
payloads, but significantly more efficient as data payload size and
inline threshold increase past a kilobyte.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2016-09-15 22:57:24 +08:00
|
|
|
|
|
|
|
enum rpcrdma_chunktype {
|
|
|
|
rpcrdma_noch = 0,
|
|
|
|
rpcrdma_readch,
|
|
|
|
rpcrdma_areadch,
|
|
|
|
rpcrdma_writech,
|
|
|
|
rpcrdma_replych
|
|
|
|
};
|
|
|
|
|
|
|
|
bool rpcrdma_prepare_send_sges(struct rpcrdma_ia *, struct rpcrdma_req *,
|
|
|
|
u32, struct xdr_buf *, enum rpcrdma_chunktype);
|
|
|
|
void rpcrdma_unmap_sges(struct rpcrdma_ia *, struct rpcrdma_req *);
|
2017-08-11 00:47:12 +08:00
|
|
|
int rpcrdma_marshal_req(struct rpcrdma_xprt *r_xprt, struct rpc_rqst *rqst);
|
2016-09-15 22:57:07 +08:00
|
|
|
void rpcrdma_set_max_header_sizes(struct rpcrdma_xprt *);
|
2016-11-29 23:53:37 +08:00
|
|
|
void rpcrdma_reply_handler(struct work_struct *work);
|
2007-09-11 01:50:12 +08:00
|
|
|
|
2017-08-04 02:30:03 +08:00
|
|
|
static inline void rpcrdma_set_xdrlen(struct xdr_buf *xdr, size_t len)
|
|
|
|
{
|
|
|
|
xdr->head[0].iov_len = len;
|
|
|
|
xdr->len = len;
|
|
|
|
}
|
|
|
|
|
2015-06-04 23:21:42 +08:00
|
|
|
/* RPC/RDMA module init - xprtrdma/transport.c
|
|
|
|
*/
|
2016-01-08 03:50:10 +08:00
|
|
|
extern unsigned int xprt_rdma_max_inline_read;
|
|
|
|
void xprt_rdma_format_addresses(struct rpc_xprt *xprt, struct sockaddr *sap);
|
|
|
|
void xprt_rdma_free_addresses(struct rpc_xprt *xprt);
|
2016-11-29 23:53:37 +08:00
|
|
|
void rpcrdma_connect_worker(struct work_struct *work);
|
2016-01-08 03:50:10 +08:00
|
|
|
void xprt_rdma_print_stats(struct rpc_xprt *xprt, struct seq_file *seq);
|
2015-06-04 23:21:42 +08:00
|
|
|
int xprt_rdma_init(void);
|
|
|
|
void xprt_rdma_cleanup(void);
|
|
|
|
|
2015-10-25 05:27:43 +08:00
|
|
|
/* Backchannel calls - xprtrdma/backchannel.c
|
|
|
|
*/
|
|
|
|
#if defined(CONFIG_SUNRPC_BACKCHANNEL)
|
|
|
|
int xprt_rdma_bc_setup(struct rpc_xprt *, unsigned int);
|
2015-10-25 05:28:32 +08:00
|
|
|
int xprt_rdma_bc_up(struct svc_serv *, struct net *);
|
2016-05-03 02:40:40 +08:00
|
|
|
size_t xprt_rdma_bc_maxpayload(struct rpc_xprt *);
|
2015-10-25 05:27:43 +08:00
|
|
|
int rpcrdma_bc_post_recv(struct rpcrdma_xprt *, unsigned int);
|
2015-10-25 05:28:08 +08:00
|
|
|
void rpcrdma_bc_receive_call(struct rpcrdma_xprt *, struct rpcrdma_rep *);
|
2015-10-25 05:27:59 +08:00
|
|
|
int rpcrdma_bc_marshal_reply(struct rpc_rqst *);
|
2015-10-25 05:27:43 +08:00
|
|
|
void xprt_rdma_bc_free_rqst(struct rpc_rqst *);
|
|
|
|
void xprt_rdma_bc_destroy(struct rpc_xprt *, unsigned int);
|
|
|
|
#endif /* CONFIG_SUNRPC_BACKCHANNEL */
|
|
|
|
|
2016-01-08 03:50:10 +08:00
|
|
|
extern struct xprt_class xprt_rdma_bc;
|
2012-02-16 01:30:00 +08:00
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
#endif /* _LINUX_SUNRPC_XPRT_RDMA_H */
|