2018-05-05 03:34:32 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
|
2007-09-11 01:50:12 +08:00
|
|
|
/*
|
2017-10-31 04:22:14 +08:00
|
|
|
* Copyright (c) 2014-2017 Oracle. All rights reserved.
|
2007-09-11 01:51:18 +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.
|
2007-09-11 01:50:12 +08:00
|
|
|
*/
|
|
|
|
|
2007-09-11 01:51:18 +08:00
|
|
|
/*
|
|
|
|
* verbs.c
|
|
|
|
*
|
|
|
|
* Encapsulates the major functions managing:
|
|
|
|
* o adapters
|
|
|
|
* o endpoints
|
|
|
|
* o connections
|
|
|
|
* o buffer memory
|
|
|
|
*/
|
|
|
|
|
2011-06-06 18:43:46 +08:00
|
|
|
#include <linux/interrupt.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2015-03-31 02:33:43 +08:00
|
|
|
#include <linux/sunrpc/addr.h>
|
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
|
|
|
#include <linux/sunrpc/svc_rdma.h>
|
2019-08-20 06:40:11 +08:00
|
|
|
#include <linux/log2.h>
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
|
|
|
|
#include <asm-generic/barrier.h>
|
xprtrdma: Reduce the number of hardway buffer allocations
While marshaling an RPC/RDMA request, the inline_{rsize,wsize}
settings determine whether an inline request is used, or whether
read or write chunks lists are built. The current default value of
these settings is 1024. Any RPC request smaller than 1024 bytes is
sent to the NFS server completely inline.
rpcrdma_buffer_create() allocates and pre-registers a set of RPC
buffers for each transport instance, also based on the inline rsize
and wsize settings.
RPC/RDMA requests and replies are built in these buffers. However,
if an RPC/RDMA request is expected to be larger than 1024, a buffer
has to be allocated and registered for that RPC, and deregistered
and released when the RPC is complete. This is known has a
"hardway allocation."
Since the introduction of NFSv4, the size of RPC requests has become
larger, and hardway allocations are thus more frequent. Hardway
allocations are significant overhead, and they waste the existing
RPC buffers pre-allocated by rpcrdma_buffer_create().
We'd like fewer hardway allocations.
Increasing the size of the pre-registered buffers is the most direct
way to do this. However, a blanket increase of the inline thresholds
has interoperability consequences.
On my 64-bit system, rpcrdma_buffer_create() requests roughly 7000
bytes for each RPC request buffer, using kmalloc(). Due to internal
fragmentation, this wastes nearly 1200 bytes because kmalloc()
already returns an 8192-byte piece of memory for a 7000-byte
allocation request, though the extra space remains unused.
So let's round up the size of the pre-allocated buffers, and make
use of the unused space in the kmalloc'd memory.
This change reduces the amount of hardway allocated memory for an
NFSv4 general connectathon run from 1322092 to 9472 bytes (99%).
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2014-05-28 22:33:59 +08:00
|
|
|
#include <asm/bitops.h>
|
2017-04-12 01:23:34 +08:00
|
|
|
|
2017-02-09 06:00:35 +08:00
|
|
|
#include <rdma/ib_cm.h>
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2007-09-11 01:50:12 +08:00
|
|
|
#include "xprt_rdma.h"
|
2018-05-08 03:27:05 +08:00
|
|
|
#include <trace/events/rpcrdma.h>
|
2007-09-11 01:50:12 +08:00
|
|
|
|
2020-01-04 00:56:32 +08:00
|
|
|
static int rpcrdma_sendctxs_create(struct rpcrdma_xprt *r_xprt);
|
|
|
|
static void rpcrdma_sendctxs_destroy(struct rpcrdma_xprt *r_xprt);
|
2019-10-18 02:31:18 +08:00
|
|
|
static void rpcrdma_sendctx_put_locked(struct rpcrdma_xprt *r_xprt,
|
|
|
|
struct rpcrdma_sendctx *sc);
|
2020-01-04 00:56:53 +08:00
|
|
|
static int rpcrdma_reqs_setup(struct rpcrdma_xprt *r_xprt);
|
2019-10-10 01:07:27 +08:00
|
|
|
static void rpcrdma_reqs_reset(struct rpcrdma_xprt *r_xprt);
|
2020-01-04 00:56:58 +08:00
|
|
|
static void rpcrdma_rep_destroy(struct rpcrdma_rep *rep);
|
2020-01-04 00:52:22 +08:00
|
|
|
static void rpcrdma_reps_unmap(struct rpcrdma_xprt *r_xprt);
|
2017-12-15 09:57:55 +08:00
|
|
|
static void rpcrdma_mrs_create(struct rpcrdma_xprt *r_xprt);
|
2019-10-10 01:07:48 +08:00
|
|
|
static void rpcrdma_mrs_destroy(struct rpcrdma_xprt *r_xprt);
|
2020-06-15 21:20:52 +08:00
|
|
|
static void rpcrdma_ep_get(struct rpcrdma_ep *ep);
|
|
|
|
static int rpcrdma_ep_put(struct rpcrdma_ep *ep);
|
2019-04-24 21:39:32 +08:00
|
|
|
static struct rpcrdma_regbuf *
|
2022-09-23 21:06:18 +08:00
|
|
|
rpcrdma_regbuf_alloc(size_t size, enum dma_data_direction direction);
|
2019-04-24 21:39:32 +08:00
|
|
|
static void rpcrdma_regbuf_dma_unmap(struct rpcrdma_regbuf *rb);
|
|
|
|
static void rpcrdma_regbuf_free(struct rpcrdma_regbuf *rb);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2019-04-24 21:40:36 +08:00
|
|
|
/* Wait for outstanding transport work to finish. ib_drain_qp
|
|
|
|
* handles the drains in the wrong order for us, so open code
|
|
|
|
* them here.
|
2018-12-19 23:58:29 +08:00
|
|
|
*/
|
|
|
|
static void rpcrdma_xprt_drain(struct rpcrdma_xprt *r_xprt)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2020-06-15 21:20:52 +08:00
|
|
|
struct rpcrdma_ep *ep = r_xprt->rx_ep;
|
|
|
|
struct rdma_cm_id *id = ep->re_id;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2021-04-20 02:02:09 +08:00
|
|
|
/* Wait for rpcrdma_post_recvs() to leave its critical
|
|
|
|
* section.
|
|
|
|
*/
|
|
|
|
if (atomic_inc_return(&ep->re_receiving) > 1)
|
|
|
|
wait_for_completion(&ep->re_done);
|
|
|
|
|
2018-12-19 23:58:29 +08:00
|
|
|
/* Flush Receives, then wait for deferred Reply work
|
|
|
|
* to complete.
|
|
|
|
*/
|
2020-02-22 06:00:54 +08:00
|
|
|
ib_drain_rq(id->qp);
|
2014-11-09 09:14:37 +08:00
|
|
|
|
2018-12-19 23:58:29 +08:00
|
|
|
/* Deferred Reply processing might have scheduled
|
|
|
|
* local invalidations.
|
|
|
|
*/
|
2020-02-22 06:00:54 +08:00
|
|
|
ib_drain_sq(id->qp);
|
2020-06-15 21:20:52 +08:00
|
|
|
|
|
|
|
rpcrdma_ep_put(ep);
|
2014-11-09 09:14:37 +08:00
|
|
|
}
|
|
|
|
|
2020-06-15 21:21:07 +08:00
|
|
|
/* Ensure xprt_force_disconnect() is invoked exactly once when a
|
|
|
|
* connection is closed or lost. (The important thing is it needs
|
|
|
|
* to be invoked "at least" once).
|
|
|
|
*/
|
2021-08-03 02:44:17 +08:00
|
|
|
void rpcrdma_force_disconnect(struct rpcrdma_ep *ep)
|
2020-06-15 21:21:07 +08:00
|
|
|
{
|
|
|
|
if (atomic_add_unless(&ep->re_force_disconnect, 1, 1))
|
|
|
|
xprt_force_disconnect(ep->re_xprt);
|
|
|
|
}
|
|
|
|
|
2020-02-22 06:00:49 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_flush_disconnect - Disconnect on flushed completion
|
2020-06-15 21:21:02 +08:00
|
|
|
* @r_xprt: transport to disconnect
|
2020-02-22 06:00:49 +08:00
|
|
|
* @wc: work completion entry
|
|
|
|
*
|
|
|
|
* Must be called in process context.
|
|
|
|
*/
|
2020-06-15 21:21:02 +08:00
|
|
|
void rpcrdma_flush_disconnect(struct rpcrdma_xprt *r_xprt, struct ib_wc *wc)
|
2020-02-22 06:00:49 +08:00
|
|
|
{
|
2020-06-15 21:21:07 +08:00
|
|
|
if (wc->status != IB_WC_SUCCESS)
|
|
|
|
rpcrdma_force_disconnect(r_xprt->rx_ep);
|
2020-02-22 06:00:49 +08:00
|
|
|
}
|
|
|
|
|
2016-03-05 00:28:53 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_wc_send - Invoked by RDMA provider for each polled Send WC
|
2019-10-18 02:31:18 +08:00
|
|
|
* @cq: completion queue
|
2020-02-22 06:00:49 +08:00
|
|
|
* @wc: WCE for a completed Send WR
|
2016-03-05 00:28:53 +08:00
|
|
|
*
|
2014-05-28 22:33:25 +08:00
|
|
|
*/
|
2020-02-22 06:00:49 +08:00
|
|
|
static void rpcrdma_wc_send(struct ib_cq *cq, struct ib_wc *wc)
|
2014-05-28 22:33:25 +08:00
|
|
|
{
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
struct ib_cqe *cqe = wc->wr_cqe;
|
|
|
|
struct rpcrdma_sendctx *sc =
|
|
|
|
container_of(cqe, struct rpcrdma_sendctx, sc_cqe);
|
2020-06-15 21:21:02 +08:00
|
|
|
struct rpcrdma_xprt *r_xprt = cq->cq_context;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
|
2016-03-05 00:28:53 +08:00
|
|
|
/* WARNING: Only wr_cqe and status are reliable at this point */
|
2020-11-10 03:39:26 +08:00
|
|
|
trace_xprtrdma_wc_send(wc, &sc->sc_cid);
|
2020-06-15 21:21:02 +08:00
|
|
|
rpcrdma_sendctx_put_locked(r_xprt, sc);
|
|
|
|
rpcrdma_flush_disconnect(r_xprt, wc);
|
2014-05-28 22:33:25 +08:00
|
|
|
}
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2016-03-05 00:28:36 +08:00
|
|
|
/**
|
2016-09-15 22:57:49 +08:00
|
|
|
* rpcrdma_wc_receive - Invoked by RDMA provider for each polled Receive WC
|
2020-02-22 06:00:49 +08:00
|
|
|
* @cq: completion queue
|
|
|
|
* @wc: WCE for a completed Receive WR
|
2016-03-05 00:28:36 +08:00
|
|
|
*
|
|
|
|
*/
|
2020-02-22 06:00:49 +08:00
|
|
|
static void rpcrdma_wc_receive(struct ib_cq *cq, struct ib_wc *wc)
|
2014-05-28 22:33:25 +08:00
|
|
|
{
|
2016-03-05 00:28:36 +08:00
|
|
|
struct ib_cqe *cqe = wc->wr_cqe;
|
|
|
|
struct rpcrdma_rep *rep = container_of(cqe, struct rpcrdma_rep,
|
|
|
|
rr_cqe);
|
2020-02-22 06:00:49 +08:00
|
|
|
struct rpcrdma_xprt *r_xprt = cq->cq_context;
|
2014-05-28 22:33:25 +08:00
|
|
|
|
2018-12-19 23:58:24 +08:00
|
|
|
/* WARNING: Only wr_cqe and status are reliable at this point */
|
2020-11-10 03:39:21 +08:00
|
|
|
trace_xprtrdma_wc_receive(wc, &rep->rr_cid);
|
2020-02-22 06:01:05 +08:00
|
|
|
--r_xprt->rx_ep->re_receive_count;
|
2015-01-22 00:02:04 +08:00
|
|
|
if (wc->status != IB_WC_SUCCESS)
|
2018-12-19 23:58:24 +08:00
|
|
|
goto out_flushed;
|
2014-05-28 22:33:25 +08:00
|
|
|
|
2015-01-22 00:02:04 +08:00
|
|
|
/* status == SUCCESS means all fields in wc are trustworthy */
|
2017-08-04 02:30:03 +08:00
|
|
|
rpcrdma_set_xdrlen(&rep->rr_hdrbuf, wc->byte_len);
|
2016-09-15 22:57:16 +08:00
|
|
|
rep->rr_wc_flags = wc->wc_flags;
|
|
|
|
rep->rr_inv_rkey = wc->ex.invalidate_rkey;
|
|
|
|
|
2017-04-12 01:23:02 +08:00
|
|
|
ib_dma_sync_single_for_cpu(rdmab_device(rep->rr_rdmabuf),
|
2015-01-22 00:04:25 +08:00
|
|
|
rdmab_addr(rep->rr_rdmabuf),
|
2017-08-04 02:30:44 +08:00
|
|
|
wc->byte_len, DMA_FROM_DEVICE);
|
2016-03-05 00:28:27 +08:00
|
|
|
|
2017-10-17 03:01:30 +08:00
|
|
|
rpcrdma_reply_handler(rep);
|
2015-01-22 00:02:04 +08:00
|
|
|
return;
|
2015-10-25 05:27:10 +08:00
|
|
|
|
2018-12-19 23:58:24 +08:00
|
|
|
out_flushed:
|
2020-06-15 21:21:02 +08:00
|
|
|
rpcrdma_flush_disconnect(r_xprt, wc);
|
2021-04-20 02:02:16 +08:00
|
|
|
rpcrdma_rep_put(&r_xprt->rx_buf, rep);
|
2014-05-28 22:33:25 +08:00
|
|
|
}
|
|
|
|
|
2020-02-22 06:01:00 +08:00
|
|
|
static void rpcrdma_update_cm_private(struct rpcrdma_ep *ep,
|
2019-10-23 22:02:09 +08:00
|
|
|
struct rdma_conn_param *param)
|
2016-09-15 22:57:07 +08:00
|
|
|
{
|
|
|
|
const struct rpcrdma_connect_private *pmsg = param->private_data;
|
|
|
|
unsigned int rsize, wsize;
|
|
|
|
|
2016-09-15 22:57:16 +08:00
|
|
|
/* Default settings for RPC-over-RDMA Version One */
|
2016-09-15 22:57:07 +08:00
|
|
|
rsize = RPCRDMA_V1_DEF_INLINE_SIZE;
|
|
|
|
wsize = RPCRDMA_V1_DEF_INLINE_SIZE;
|
|
|
|
|
|
|
|
if (pmsg &&
|
|
|
|
pmsg->cp_magic == rpcrdma_cmp_magic &&
|
|
|
|
pmsg->cp_version == RPCRDMA_CMP_VERSION) {
|
|
|
|
rsize = rpcrdma_decode_buffer_size(pmsg->cp_send_size);
|
|
|
|
wsize = rpcrdma_decode_buffer_size(pmsg->cp_recv_size);
|
|
|
|
}
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
if (rsize < ep->re_inline_recv)
|
|
|
|
ep->re_inline_recv = rsize;
|
|
|
|
if (wsize < ep->re_inline_send)
|
|
|
|
ep->re_inline_send = wsize;
|
2019-10-23 22:02:09 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
rpcrdma_set_max_header_sizes(ep);
|
2016-09-15 22:57:07 +08:00
|
|
|
}
|
|
|
|
|
2018-10-02 02:25:47 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_cm_event_handler - Handle RDMA CM events
|
|
|
|
* @id: rdma_cm_id on which an event has occurred
|
|
|
|
* @event: details of the event
|
|
|
|
*
|
|
|
|
* Called with @id's mutex held. Returns 1 if caller should
|
|
|
|
* destroy @id, otherwise 0.
|
|
|
|
*/
|
2007-09-11 01:51:18 +08:00
|
|
|
static int
|
2018-10-02 02:25:47 +08:00
|
|
|
rpcrdma_cm_event_handler(struct rdma_cm_id *id, struct rdma_cm_event *event)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2020-02-22 06:01:00 +08:00
|
|
|
struct sockaddr *sap = (struct sockaddr *)&id->route.addr.dst_addr;
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep = id->context;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2018-10-02 02:25:47 +08:00
|
|
|
might_sleep();
|
|
|
|
|
2007-09-11 01:51:18 +08:00
|
|
|
switch (event->event) {
|
|
|
|
case RDMA_CM_EVENT_ADDR_RESOLVED:
|
|
|
|
case RDMA_CM_EVENT_ROUTE_RESOLVED:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_async_rc = 0;
|
|
|
|
complete(&ep->re_done);
|
2018-10-02 02:26:03 +08:00
|
|
|
return 0;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_ADDR_ERROR:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_async_rc = -EPROTO;
|
|
|
|
complete(&ep->re_done);
|
2018-10-02 02:26:03 +08:00
|
|
|
return 0;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_ROUTE_ERROR:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_async_rc = -ENETUNREACH;
|
|
|
|
complete(&ep->re_done);
|
2018-10-02 02:26:03 +08:00
|
|
|
return 0;
|
2017-04-12 01:23:10 +08:00
|
|
|
case RDMA_CM_EVENT_DEVICE_REMOVAL:
|
2020-02-22 06:01:00 +08:00
|
|
|
pr_info("rpcrdma: removing device %s for %pISpc\n",
|
|
|
|
ep->re_id->device->name, sap);
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2020-02-22 06:01:05 +08:00
|
|
|
case RDMA_CM_EVENT_ADDR_CHANGE:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_connect_status = -ENODEV;
|
2020-02-22 06:01:05 +08:00
|
|
|
goto disconnected;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_ESTABLISHED:
|
2020-06-15 21:20:52 +08:00
|
|
|
rpcrdma_ep_get(ep);
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_connect_status = 1;
|
2020-02-22 06:01:00 +08:00
|
|
|
rpcrdma_update_cm_private(ep, &event->param.conn);
|
|
|
|
trace_xprtrdma_inline_thresh(ep);
|
2020-02-22 06:00:54 +08:00
|
|
|
wake_up_all(&ep->re_connect_wait);
|
2018-10-02 02:26:08 +08:00
|
|
|
break;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_CONNECT_ERROR:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_connect_status = -ENOTCONN;
|
2020-06-28 00:35:20 +08:00
|
|
|
goto wake_connect_worker;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_UNREACHABLE:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_connect_status = -ENETUNREACH;
|
2020-06-28 00:35:20 +08:00
|
|
|
goto wake_connect_worker;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_REJECTED:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_connect_status = -ECONNREFUSED;
|
2017-02-09 06:00:35 +08:00
|
|
|
if (event->status == IB_CM_REJ_STALE_CONN)
|
2020-06-28 00:35:09 +08:00
|
|
|
ep->re_connect_status = -ENOTCONN;
|
2020-06-28 00:35:20 +08:00
|
|
|
wake_connect_worker:
|
|
|
|
wake_up_all(&ep->re_connect_wait);
|
|
|
|
return 0;
|
2007-09-11 01:51:18 +08:00
|
|
|
case RDMA_CM_EVENT_DISCONNECTED:
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_connect_status = -ECONNABORTED;
|
2018-10-02 02:26:08 +08:00
|
|
|
disconnected:
|
2020-06-15 21:21:07 +08:00
|
|
|
rpcrdma_force_disconnect(ep);
|
2020-06-15 21:20:52 +08:00
|
|
|
return rpcrdma_ep_put(ep);
|
2007-09-11 01:51:18 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
static struct rdma_cm_id *rpcrdma_create_id(struct rpcrdma_xprt *r_xprt,
|
|
|
|
struct rpcrdma_ep *ep)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2016-11-29 23:52:40 +08:00
|
|
|
unsigned long wtimeout = msecs_to_jiffies(RDMA_RESOLVE_TIMEOUT) + 1;
|
2020-02-22 06:00:54 +08:00
|
|
|
struct rpc_xprt *xprt = &r_xprt->rx_xprt;
|
2007-09-11 01:51:18 +08:00
|
|
|
struct rdma_cm_id *id;
|
|
|
|
int rc;
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
init_completion(&ep->re_done);
|
2008-10-10 03:01:31 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
id = rdma_create_id(xprt->xprt_net, rpcrdma_cm_event_handler, ep,
|
2020-02-22 06:00:54 +08:00
|
|
|
RDMA_PS_TCP, IB_QPT_RC);
|
2018-12-19 23:59:39 +08:00
|
|
|
if (IS_ERR(id))
|
2007-09-11 01:51:18 +08:00
|
|
|
return id;
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_async_rc = -ETIMEDOUT;
|
|
|
|
rc = rdma_resolve_addr(id, NULL, (struct sockaddr *)&xprt->addr,
|
2017-12-15 09:56:58 +08:00
|
|
|
RDMA_RESOLVE_TIMEOUT);
|
2018-12-19 23:59:39 +08:00
|
|
|
if (rc)
|
2007-09-11 01:51:18 +08:00
|
|
|
goto out;
|
2020-02-22 06:00:54 +08:00
|
|
|
rc = wait_for_completion_interruptible_timeout(&ep->re_done, wtimeout);
|
2019-10-23 22:01:58 +08:00
|
|
|
if (rc < 0)
|
2016-11-29 23:52:40 +08:00
|
|
|
goto out;
|
2015-08-04 01:05:04 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
rc = ep->re_async_rc;
|
2007-09-11 01:51:18 +08:00
|
|
|
if (rc)
|
|
|
|
goto out;
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_async_rc = -ETIMEDOUT;
|
2007-09-11 01:51:18 +08:00
|
|
|
rc = rdma_resolve_route(id, RDMA_RESOLVE_TIMEOUT);
|
2018-12-19 23:59:39 +08:00
|
|
|
if (rc)
|
2017-04-12 01:23:34 +08:00
|
|
|
goto out;
|
2020-02-22 06:00:54 +08:00
|
|
|
rc = wait_for_completion_interruptible_timeout(&ep->re_done, wtimeout);
|
2019-10-23 22:01:58 +08:00
|
|
|
if (rc < 0)
|
2017-04-12 01:23:34 +08:00
|
|
|
goto out;
|
2020-02-22 06:00:54 +08:00
|
|
|
rc = ep->re_async_rc;
|
2007-09-11 01:51:18 +08:00
|
|
|
if (rc)
|
2017-04-12 01:23:34 +08:00
|
|
|
goto out;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
|
|
|
return id;
|
2017-04-12 01:23:34 +08:00
|
|
|
|
2007-09-11 01:51:18 +08:00
|
|
|
out:
|
|
|
|
rdma_destroy_id(id);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
2020-06-15 21:20:52 +08:00
|
|
|
static void rpcrdma_ep_destroy(struct kref *kref)
|
2020-02-22 06:01:05 +08:00
|
|
|
{
|
|
|
|
struct rpcrdma_ep *ep = container_of(kref, struct rpcrdma_ep, re_kref);
|
|
|
|
|
|
|
|
if (ep->re_id->qp) {
|
|
|
|
rdma_destroy_qp(ep->re_id);
|
|
|
|
ep->re_id->qp = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ep->re_attr.recv_cq)
|
|
|
|
ib_free_cq(ep->re_attr.recv_cq);
|
|
|
|
ep->re_attr.recv_cq = NULL;
|
|
|
|
if (ep->re_attr.send_cq)
|
|
|
|
ib_free_cq(ep->re_attr.send_cq);
|
|
|
|
ep->re_attr.send_cq = NULL;
|
|
|
|
|
|
|
|
if (ep->re_pd)
|
|
|
|
ib_dealloc_pd(ep->re_pd);
|
|
|
|
ep->re_pd = NULL;
|
|
|
|
|
|
|
|
kfree(ep);
|
|
|
|
module_put(THIS_MODULE);
|
|
|
|
}
|
|
|
|
|
2020-06-15 21:20:52 +08:00
|
|
|
static noinline void rpcrdma_ep_get(struct rpcrdma_ep *ep)
|
|
|
|
{
|
|
|
|
kref_get(&ep->re_kref);
|
|
|
|
}
|
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
/* Returns:
|
|
|
|
* %0 if @ep still has a positive kref count, or
|
|
|
|
* %1 if @ep was destroyed successfully.
|
2007-09-11 01:51:18 +08:00
|
|
|
*/
|
2020-06-15 21:20:52 +08:00
|
|
|
static noinline int rpcrdma_ep_put(struct rpcrdma_ep *ep)
|
2020-02-22 06:01:05 +08:00
|
|
|
{
|
2020-06-15 21:20:52 +08:00
|
|
|
return kref_put(&ep->re_kref, rpcrdma_ep_destroy);
|
2020-02-22 06:01:05 +08:00
|
|
|
}
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:00:38 +08:00
|
|
|
static int rpcrdma_ep_create(struct rpcrdma_xprt *r_xprt)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_connect_private *pmsg;
|
|
|
|
struct ib_device *device;
|
2020-02-22 06:00:38 +08:00
|
|
|
struct rdma_cm_id *id;
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep;
|
2016-03-05 00:28:53 +08:00
|
|
|
int rc;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2022-09-23 21:06:30 +08:00
|
|
|
ep = kzalloc(sizeof(*ep), XPRTRDMA_GFP_FLAGS);
|
2020-02-22 06:01:05 +08:00
|
|
|
if (!ep)
|
2020-06-28 00:35:15 +08:00
|
|
|
return -ENOTCONN;
|
2020-02-22 06:01:05 +08:00
|
|
|
ep->re_xprt = &r_xprt->rx_xprt;
|
|
|
|
kref_init(&ep->re_kref);
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
id = rpcrdma_create_id(r_xprt, ep);
|
2020-02-22 06:01:05 +08:00
|
|
|
if (IS_ERR(id)) {
|
2020-06-28 00:35:04 +08:00
|
|
|
kfree(ep);
|
|
|
|
return PTR_ERR(id);
|
2020-02-22 06:01:05 +08:00
|
|
|
}
|
|
|
|
__module_get(THIS_MODULE);
|
|
|
|
device = id->device;
|
|
|
|
ep->re_id = id;
|
2021-04-20 02:02:09 +08:00
|
|
|
reinit_completion(&ep->re_done);
|
2020-02-22 06:00:38 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_max_requests = r_xprt->rx_xprt.max_reqs;
|
|
|
|
ep->re_inline_send = xprt_rdma_max_inline_write;
|
|
|
|
ep->re_inline_recv = xprt_rdma_max_inline_read;
|
2020-02-22 06:01:05 +08:00
|
|
|
rc = frwr_query_device(ep, device);
|
2018-05-05 03:34:48 +08:00
|
|
|
if (rc)
|
2020-02-22 06:00:38 +08:00
|
|
|
goto out_destroy;
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
r_xprt->rx_buf.rb_max_requests = cpu_to_be32(ep->re_max_requests);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_attr.srq = NULL;
|
|
|
|
ep->re_attr.cap.max_inline_data = 0;
|
|
|
|
ep->re_attr.sq_sig_type = IB_SIGNAL_REQ_WR;
|
|
|
|
ep->re_attr.qp_type = IB_QPT_RC;
|
|
|
|
ep->re_attr.port_num = ~0;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_send_batch = ep->re_max_requests >> 3;
|
|
|
|
ep->re_send_count = ep->re_send_batch;
|
|
|
|
init_waitqueue_head(&ep->re_connect_wait);
|
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
ep->re_attr.send_cq = ib_alloc_cq_any(device, r_xprt,
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_attr.cap.max_send_wr,
|
|
|
|
IB_POLL_WORKQUEUE);
|
|
|
|
if (IS_ERR(ep->re_attr.send_cq)) {
|
|
|
|
rc = PTR_ERR(ep->re_attr.send_cq);
|
2022-01-26 04:06:46 +08:00
|
|
|
ep->re_attr.send_cq = NULL;
|
2020-02-22 06:00:12 +08:00
|
|
|
goto out_destroy;
|
2007-09-11 01:51:18 +08:00
|
|
|
}
|
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
ep->re_attr.recv_cq = ib_alloc_cq_any(device, r_xprt,
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_attr.cap.max_recv_wr,
|
|
|
|
IB_POLL_WORKQUEUE);
|
|
|
|
if (IS_ERR(ep->re_attr.recv_cq)) {
|
|
|
|
rc = PTR_ERR(ep->re_attr.recv_cq);
|
2022-01-26 04:06:46 +08:00
|
|
|
ep->re_attr.recv_cq = NULL;
|
2020-02-22 06:00:12 +08:00
|
|
|
goto out_destroy;
|
2014-05-28 22:33:25 +08:00
|
|
|
}
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_receive_count = 0;
|
2014-05-28 22:33:25 +08:00
|
|
|
|
2007-09-11 01:51:18 +08:00
|
|
|
/* Initialize cma parameters */
|
2020-02-22 06:00:54 +08:00
|
|
|
memset(&ep->re_remote_cma, 0, sizeof(ep->re_remote_cma));
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2016-09-15 22:57:07 +08:00
|
|
|
/* Prepare RDMA-CM private message */
|
2020-02-22 06:01:05 +08:00
|
|
|
pmsg = &ep->re_cm_private;
|
2016-09-15 22:57:07 +08:00
|
|
|
pmsg->cp_magic = rpcrdma_cmp_magic;
|
|
|
|
pmsg->cp_version = RPCRDMA_CMP_VERSION;
|
2018-12-19 23:59:01 +08:00
|
|
|
pmsg->cp_flags |= RPCRDMA_CMP_F_SND_W_INV_OK;
|
2020-02-22 06:00:54 +08:00
|
|
|
pmsg->cp_send_size = rpcrdma_encode_buffer_size(ep->re_inline_send);
|
|
|
|
pmsg->cp_recv_size = rpcrdma_encode_buffer_size(ep->re_inline_recv);
|
|
|
|
ep->re_remote_cma.private_data = pmsg;
|
|
|
|
ep->re_remote_cma.private_data_len = sizeof(*pmsg);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
|
|
|
/* Client offers RDMA Read but does not initiate */
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_remote_cma.initiator_depth = 0;
|
|
|
|
ep->re_remote_cma.responder_resources =
|
2020-02-22 06:01:05 +08:00
|
|
|
min_t(int, U8_MAX, device->attrs.max_qp_rd_atom);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2016-05-03 02:43:03 +08:00
|
|
|
/* Limit transport retries so client can detect server
|
|
|
|
* GID changes quickly. RPC layer handles re-establishing
|
|
|
|
* transport connection and retransmission.
|
|
|
|
*/
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_remote_cma.retry_count = 6;
|
2016-05-03 02:43:03 +08:00
|
|
|
|
|
|
|
/* RPC-over-RDMA handles its own flow control. In addition,
|
|
|
|
* make all RNR NAKs visible so we know that RPC-over-RDMA
|
|
|
|
* flow control is working correctly (no NAKs should be seen).
|
|
|
|
*/
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_remote_cma.flow_control = 0;
|
|
|
|
ep->re_remote_cma.rnr_retry_count = 0;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
ep->re_pd = ib_alloc_pd(device, 0);
|
2020-02-22 06:00:54 +08:00
|
|
|
if (IS_ERR(ep->re_pd)) {
|
|
|
|
rc = PTR_ERR(ep->re_pd);
|
2022-01-26 04:06:46 +08:00
|
|
|
ep->re_pd = NULL;
|
2020-02-22 06:00:33 +08:00
|
|
|
goto out_destroy;
|
|
|
|
}
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
rc = rdma_create_qp(id, ep->re_pd, &ep->re_attr);
|
2020-02-22 06:00:12 +08:00
|
|
|
if (rc)
|
|
|
|
goto out_destroy;
|
2020-02-22 06:00:54 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
r_xprt->rx_ep = ep;
|
2007-09-11 01:51:18 +08:00
|
|
|
return 0;
|
|
|
|
|
2020-02-22 06:00:12 +08:00
|
|
|
out_destroy:
|
2020-06-15 21:20:52 +08:00
|
|
|
rpcrdma_ep_put(ep);
|
2020-02-22 06:00:38 +08:00
|
|
|
rdma_destroy_id(id);
|
2007-09-11 01:51:18 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_xprt_connect - Connect an unconnected transport
|
|
|
|
* @r_xprt: controlling transport instance
|
|
|
|
*
|
|
|
|
* Returns 0 on success or a negative errno.
|
2007-09-11 01:51:18 +08:00
|
|
|
*/
|
2020-02-22 06:00:28 +08:00
|
|
|
int rpcrdma_xprt_connect(struct rpcrdma_xprt *r_xprt)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2018-10-02 02:26:08 +08:00
|
|
|
struct rpc_xprt *xprt = &r_xprt->rx_xprt;
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep;
|
2017-04-12 01:23:18 +08:00
|
|
|
int rc;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:00:38 +08:00
|
|
|
rc = rpcrdma_ep_create(r_xprt);
|
|
|
|
if (rc)
|
2020-02-22 06:01:05 +08:00
|
|
|
return rc;
|
|
|
|
ep = r_xprt->rx_ep;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2018-10-02 02:26:08 +08:00
|
|
|
xprt_clear_connected(xprt);
|
2019-10-10 01:07:32 +08:00
|
|
|
rpcrdma_reset_cwnd(r_xprt);
|
2020-06-15 21:20:52 +08:00
|
|
|
|
|
|
|
/* Bump the ep's reference count while there are
|
|
|
|
* outstanding Receives.
|
|
|
|
*/
|
|
|
|
rpcrdma_ep_get(ep);
|
2021-04-20 02:02:41 +08:00
|
|
|
rpcrdma_post_recvs(r_xprt, 1, true);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
rc = rdma_connect(ep->re_id, &ep->re_remote_cma);
|
2018-12-19 23:59:39 +08:00
|
|
|
if (rc)
|
2007-09-11 01:51:18 +08:00
|
|
|
goto out;
|
|
|
|
|
2019-08-27 01:12:51 +08:00
|
|
|
if (xprt->reestablish_timeout < RPCRDMA_INIT_REEST_TO)
|
|
|
|
xprt->reestablish_timeout = RPCRDMA_INIT_REEST_TO;
|
2020-02-22 06:00:54 +08:00
|
|
|
wait_event_interruptible(ep->re_connect_wait,
|
|
|
|
ep->re_connect_status != 0);
|
|
|
|
if (ep->re_connect_status <= 0) {
|
|
|
|
rc = ep->re_connect_status;
|
2017-02-09 06:00:35 +08:00
|
|
|
goto out;
|
2007-09-11 01:51:18 +08:00
|
|
|
}
|
|
|
|
|
2020-06-28 00:35:15 +08:00
|
|
|
rc = rpcrdma_sendctxs_create(r_xprt);
|
|
|
|
if (rc) {
|
|
|
|
rc = -ENOTCONN;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2020-01-04 00:56:53 +08:00
|
|
|
rc = rpcrdma_reqs_setup(r_xprt);
|
2020-06-28 00:35:15 +08:00
|
|
|
if (rc) {
|
|
|
|
rc = -ENOTCONN;
|
2020-01-04 00:56:53 +08:00
|
|
|
goto out;
|
2020-06-28 00:35:15 +08:00
|
|
|
}
|
2019-10-10 01:07:48 +08:00
|
|
|
rpcrdma_mrs_create(r_xprt);
|
2021-10-05 22:17:59 +08:00
|
|
|
frwr_wp_create(r_xprt);
|
2018-05-05 03:35:20 +08:00
|
|
|
|
2007-09-11 01:51:18 +08:00
|
|
|
out:
|
2019-10-23 22:01:58 +08:00
|
|
|
trace_xprtrdma_connect(r_xprt, rc);
|
2007-09-11 01:51:18 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2018-12-19 23:58:29 +08:00
|
|
|
/**
|
2020-02-22 06:00:28 +08:00
|
|
|
* rpcrdma_xprt_disconnect - Disconnect underlying transport
|
|
|
|
* @r_xprt: controlling transport instance
|
2007-09-11 01:51:18 +08:00
|
|
|
*
|
2019-10-10 01:07:48 +08:00
|
|
|
* Caller serializes. Either the transport send lock is held,
|
|
|
|
* or we're being called to destroy the transport.
|
2020-02-22 06:01:05 +08:00
|
|
|
*
|
|
|
|
* On return, @r_xprt is completely divested of all hardware
|
|
|
|
* resources and prepared for the next ->connect operation.
|
2007-09-11 01:51:18 +08:00
|
|
|
*/
|
2020-02-22 06:00:28 +08:00
|
|
|
void rpcrdma_xprt_disconnect(struct rpcrdma_xprt *r_xprt)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep = r_xprt->rx_ep;
|
|
|
|
struct rdma_cm_id *id;
|
|
|
|
int rc;
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
if (!ep)
|
2020-02-22 06:00:44 +08:00
|
|
|
return;
|
2020-02-22 06:00:12 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
id = ep->re_id;
|
2020-02-22 06:00:12 +08:00
|
|
|
rc = rdma_disconnect(id);
|
2018-12-19 23:58:29 +08:00
|
|
|
trace_xprtrdma_disconnect(r_xprt, rc);
|
2016-05-03 02:41:47 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
rpcrdma_xprt_drain(r_xprt);
|
2020-02-22 06:00:44 +08:00
|
|
|
rpcrdma_reps_unmap(r_xprt);
|
2019-10-10 01:07:27 +08:00
|
|
|
rpcrdma_reqs_reset(r_xprt);
|
2019-10-10 01:07:48 +08:00
|
|
|
rpcrdma_mrs_destroy(r_xprt);
|
2020-01-04 00:56:32 +08:00
|
|
|
rpcrdma_sendctxs_destroy(r_xprt);
|
2020-02-22 06:00:12 +08:00
|
|
|
|
2020-06-15 21:20:52 +08:00
|
|
|
if (rpcrdma_ep_put(ep))
|
2020-02-22 06:00:44 +08:00
|
|
|
rdma_destroy_id(id);
|
2020-02-22 06:01:05 +08:00
|
|
|
|
|
|
|
r_xprt->rx_ep = NULL;
|
2007-09-11 01:51:18 +08:00
|
|
|
}
|
|
|
|
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
/* Fixed-size circular FIFO queue. This implementation is wait-free and
|
|
|
|
* lock-free.
|
|
|
|
*
|
|
|
|
* Consumer is the code path that posts Sends. This path dequeues a
|
|
|
|
* sendctx for use by a Send operation. Multiple consumer threads
|
|
|
|
* are serialized by the RPC transport lock, which allows only one
|
|
|
|
* ->send_request call at a time.
|
|
|
|
*
|
|
|
|
* Producer is the code path that handles Send completions. This path
|
|
|
|
* enqueues a sendctx that has been completed. Multiple producer
|
|
|
|
* threads are serialized by the ib_poll_cq() function.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* rpcrdma_sendctxs_destroy() assumes caller has already quiesced
|
2019-04-24 21:40:36 +08:00
|
|
|
* queue activity, and rpcrdma_xprt_drain has flushed all remaining
|
|
|
|
* Send requests.
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
*/
|
2020-01-04 00:56:32 +08:00
|
|
|
static void rpcrdma_sendctxs_destroy(struct rpcrdma_xprt *r_xprt)
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
{
|
2020-01-04 00:56:32 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
unsigned long i;
|
|
|
|
|
2020-01-04 00:56:32 +08:00
|
|
|
if (!buf->rb_sc_ctxs)
|
|
|
|
return;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
for (i = 0; i <= buf->rb_sc_last; i++)
|
|
|
|
kfree(buf->rb_sc_ctxs[i]);
|
|
|
|
kfree(buf->rb_sc_ctxs);
|
2020-01-04 00:56:32 +08:00
|
|
|
buf->rb_sc_ctxs = NULL;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
}
|
|
|
|
|
2020-01-04 00:56:27 +08:00
|
|
|
static struct rpcrdma_sendctx *rpcrdma_sendctx_create(struct rpcrdma_ep *ep)
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
{
|
|
|
|
struct rpcrdma_sendctx *sc;
|
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
sc = kzalloc(struct_size(sc, sc_sges, ep->re_attr.cap.max_send_sge),
|
2022-09-23 21:06:30 +08:00
|
|
|
XPRTRDMA_GFP_FLAGS);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
if (!sc)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
sc->sc_cqe.done = rpcrdma_wc_send;
|
2020-11-10 03:39:26 +08:00
|
|
|
sc->sc_cid.ci_queue_id = ep->re_attr.send_cq->res.id;
|
|
|
|
sc->sc_cid.ci_completion_id =
|
|
|
|
atomic_inc_return(&ep->re_completion_ids);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
return sc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int rpcrdma_sendctxs_create(struct rpcrdma_xprt *r_xprt)
|
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
|
|
|
struct rpcrdma_sendctx *sc;
|
|
|
|
unsigned long i;
|
|
|
|
|
|
|
|
/* Maximum number of concurrent outstanding Send WRs. Capping
|
|
|
|
* the circular queue size stops Send Queue overflow by causing
|
|
|
|
* the ->send_request call to fail temporarily before too many
|
|
|
|
* Sends are posted.
|
|
|
|
*/
|
2020-02-22 06:01:05 +08:00
|
|
|
i = r_xprt->rx_ep->re_max_requests + RPCRDMA_MAX_BC_REQUESTS;
|
2022-09-23 21:06:30 +08:00
|
|
|
buf->rb_sc_ctxs = kcalloc(i, sizeof(sc), XPRTRDMA_GFP_FLAGS);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
if (!buf->rb_sc_ctxs)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
buf->rb_sc_last = i - 1;
|
|
|
|
for (i = 0; i <= buf->rb_sc_last; i++) {
|
2020-02-22 06:01:05 +08:00
|
|
|
sc = rpcrdma_sendctx_create(r_xprt->rx_ep);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
if (!sc)
|
2019-01-05 21:06:48 +08:00
|
|
|
return -ENOMEM;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
|
|
|
|
buf->rb_sc_ctxs[i] = sc;
|
|
|
|
}
|
|
|
|
|
2020-01-04 00:56:32 +08:00
|
|
|
buf->rb_sc_head = 0;
|
|
|
|
buf->rb_sc_tail = 0;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The sendctx queue is not guaranteed to have a size that is a
|
|
|
|
* power of two, thus the helpers in circ_buf.h cannot be used.
|
|
|
|
* The other option is to use modulus (%), which can be expensive.
|
|
|
|
*/
|
|
|
|
static unsigned long rpcrdma_sendctx_next(struct rpcrdma_buffer *buf,
|
|
|
|
unsigned long item)
|
|
|
|
{
|
|
|
|
return likely(item < buf->rb_sc_last) ? item + 1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rpcrdma_sendctx_get_locked - Acquire a send context
|
2019-04-24 21:39:53 +08:00
|
|
|
* @r_xprt: controlling transport instance
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
*
|
|
|
|
* Returns pointer to a free send completion context; or NULL if
|
|
|
|
* the queue is empty.
|
|
|
|
*
|
|
|
|
* Usage: Called to acquire an SGE array before preparing a Send WR.
|
|
|
|
*
|
2019-04-24 21:39:53 +08:00
|
|
|
* The caller serializes calls to this function (per transport), and
|
|
|
|
* provides an effective memory barrier that flushes the new value
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
* of rb_sc_head.
|
|
|
|
*/
|
2019-04-24 21:39:53 +08:00
|
|
|
struct rpcrdma_sendctx *rpcrdma_sendctx_get_locked(struct rpcrdma_xprt *r_xprt)
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
{
|
2019-04-24 21:39:53 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
struct rpcrdma_sendctx *sc;
|
|
|
|
unsigned long next_head;
|
|
|
|
|
|
|
|
next_head = rpcrdma_sendctx_next(buf, buf->rb_sc_head);
|
|
|
|
|
|
|
|
if (next_head == READ_ONCE(buf->rb_sc_tail))
|
|
|
|
goto out_emptyq;
|
|
|
|
|
|
|
|
/* ORDER: item must be accessed _before_ head is updated */
|
|
|
|
sc = buf->rb_sc_ctxs[next_head];
|
|
|
|
|
|
|
|
/* Releasing the lock in the caller acts as a memory
|
|
|
|
* barrier that flushes rb_sc_head.
|
|
|
|
*/
|
|
|
|
buf->rb_sc_head = next_head;
|
|
|
|
|
|
|
|
return sc;
|
|
|
|
|
|
|
|
out_emptyq:
|
|
|
|
/* The queue is "empty" if there have not been enough Send
|
|
|
|
* completions recently. This is a sign the Send Queue is
|
|
|
|
* backing up. Cause the caller to pause and try again.
|
|
|
|
*/
|
2019-06-19 22:32:48 +08:00
|
|
|
xprt_wait_for_buffer_space(&r_xprt->rx_xprt);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
r_xprt->rx_stats.empty_sendctx_q++;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* rpcrdma_sendctx_put_locked - Release a send context
|
2019-10-18 02:31:18 +08:00
|
|
|
* @r_xprt: controlling transport instance
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
* @sc: send context to release
|
|
|
|
*
|
|
|
|
* Usage: Called from Send completion to return a sendctxt
|
|
|
|
* to the queue.
|
|
|
|
*
|
2019-04-24 21:39:53 +08:00
|
|
|
* The caller serializes calls to this function (per transport).
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
*/
|
2019-10-18 02:31:18 +08:00
|
|
|
static void rpcrdma_sendctx_put_locked(struct rpcrdma_xprt *r_xprt,
|
|
|
|
struct rpcrdma_sendctx *sc)
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
{
|
2019-10-18 02:31:18 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
unsigned long next_tail;
|
|
|
|
|
2019-04-24 21:39:53 +08:00
|
|
|
/* Unmap SGEs of previously completed but unsignaled
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
* Sends by walking up the queue until @sc is found.
|
|
|
|
*/
|
|
|
|
next_tail = buf->rb_sc_tail;
|
|
|
|
do {
|
|
|
|
next_tail = rpcrdma_sendctx_next(buf, next_tail);
|
|
|
|
|
|
|
|
/* ORDER: item must be accessed _before_ tail is updated */
|
2019-04-24 21:39:53 +08:00
|
|
|
rpcrdma_sendctx_unmap(buf->rb_sc_ctxs[next_tail]);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
|
|
|
|
} while (buf->rb_sc_ctxs[next_tail] != sc);
|
|
|
|
|
|
|
|
/* Paired with READ_ONCE */
|
|
|
|
smp_store_release(&buf->rb_sc_tail, next_tail);
|
2018-05-05 03:35:57 +08:00
|
|
|
|
2019-10-18 02:31:18 +08:00
|
|
|
xprt_write_space(&r_xprt->rx_xprt);
|
xprtrdma: Add data structure to manage RDMA Send arguments
Problem statement:
Recently Sagi Grimberg <sagi@grimberg.me> observed that kernel RDMA-
enabled storage initiators don't handle delayed Send completion
correctly. If Send completion is delayed beyond the end of a ULP
transaction, the ULP may release resources that are still being used
by the HCA to complete a long-running Send operation.
This is a common design trait amongst our initiators. Most Send
operations are faster than the ULP transaction they are part of.
Waiting for a completion for these is typically unnecessary.
Infrequently, a network partition or some other problem crops up
where an ordering problem can occur. In NFS parlance, the RPC Reply
arrives and completes the RPC, but the HCA is still retrying the
Send WR that conveyed the RPC Call. In this case, the HCA can try
to use memory that has been invalidated or DMA unmapped, and the
connection is lost. If that memory has been re-used for something
else (possibly not related to NFS), and the Send retransmission
exposes that data on the wire.
Thus we cannot assume that it is safe to release Send-related
resources just because a ULP reply has arrived.
After some analysis, we have determined that the completion
housekeeping will not be difficult for xprtrdma:
- Inline Send buffers are registered via the local DMA key, and
are already left DMA mapped for the lifetime of a transport
connection, thus no additional handling is necessary for those
- Gathered Sends involving page cache pages _will_ need to
DMA unmap those pages after the Send completes. But like
inline send buffers, they are registered via the local DMA key,
and thus will not need to be invalidated
In addition, RPC completion will need to wait for Send completion
in the latter case. However, nearly always, the Send that conveys
the RPC Call will have completed long before the RPC Reply
arrives, and thus no additional latency will be accrued.
Design notes:
In this patch, the rpcrdma_sendctx object is introduced, and a
lock-free circular queue is added to manage a set of them per
transport.
The RPC client's send path already prevents sending more than one
RPC Call at the same time. This allows us to treat the consumer
side of the queue (rpcrdma_sendctx_get_locked) as if there is a
single consumer thread.
The producer side of the queue (rpcrdma_sendctx_put_locked) is
invoked only from the Send completion handler, which is a single
thread of execution (soft IRQ).
The only care that needs to be taken is with the tail index, which
is shared between the producer and consumer. Only the producer
updates the tail index. The consumer compares the head with the
tail to ensure that the a sendctx that is in use is never handed
out again (or, expressed more conventionally, the queue is empty).
When the sendctx queue empties completely, there are enough Sends
outstanding that posting more Send operations can result in a Send
Queue overflow. In this case, the ULP is told to wait and try again.
This introduces strong Send Queue accounting to xprtrdma.
As a final touch, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
suggested a mechanism that does not require signaling every Send.
We signal once every N Sends, and perform SGE unmapping of N Send
operations during that one completion.
Reported-by: Sagi Grimberg <sagi@grimberg.me>
Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2017-10-20 22:48:12 +08:00
|
|
|
}
|
|
|
|
|
2016-06-30 01:54:00 +08:00
|
|
|
static void
|
2017-12-15 09:57:55 +08:00
|
|
|
rpcrdma_mrs_create(struct rpcrdma_xprt *r_xprt)
|
2016-06-30 01:54:00 +08:00
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep = r_xprt->rx_ep;
|
2022-09-23 21:06:24 +08:00
|
|
|
struct ib_device *device = ep->re_id->device;
|
2016-06-30 01:54:00 +08:00
|
|
|
unsigned int count;
|
|
|
|
|
2022-09-23 21:06:24 +08:00
|
|
|
/* Try to allocate enough to perform one full-sized I/O */
|
2020-02-22 06:00:54 +08:00
|
|
|
for (count = 0; count < ep->re_max_rdma_segs; count++) {
|
2017-12-15 09:57:55 +08:00
|
|
|
struct rpcrdma_mr *mr;
|
2016-06-30 01:54:00 +08:00
|
|
|
int rc;
|
|
|
|
|
2022-09-23 21:06:24 +08:00
|
|
|
mr = kzalloc_node(sizeof(*mr), XPRTRDMA_GFP_FLAGS,
|
|
|
|
ibdev_to_node(device));
|
2017-12-15 09:57:55 +08:00
|
|
|
if (!mr)
|
2016-06-30 01:54:00 +08:00
|
|
|
break;
|
|
|
|
|
2020-02-22 06:00:17 +08:00
|
|
|
rc = frwr_mr_init(r_xprt, mr);
|
2016-06-30 01:54:00 +08:00
|
|
|
if (rc) {
|
2017-12-15 09:57:55 +08:00
|
|
|
kfree(mr);
|
2016-06-30 01:54:00 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_lock(&buf->rb_lock);
|
2019-10-10 01:07:43 +08:00
|
|
|
rpcrdma_mr_push(mr, &buf->rb_mrs);
|
2019-08-20 06:42:31 +08:00
|
|
|
list_add(&mr->mr_all, &buf->rb_all_mrs);
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_unlock(&buf->rb_lock);
|
2016-06-30 01:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
r_xprt->rx_stats.mrs_allocated += count;
|
2017-12-21 05:31:21 +08:00
|
|
|
trace_xprtrdma_createmrs(r_xprt, count);
|
2016-06-30 01:54:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
rpcrdma_mr_refresh_worker(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = container_of(work, struct rpcrdma_buffer,
|
2019-08-20 06:45:37 +08:00
|
|
|
rb_refresh_worker);
|
2016-06-30 01:54:00 +08:00
|
|
|
struct rpcrdma_xprt *r_xprt = container_of(buf, struct rpcrdma_xprt,
|
|
|
|
rx_buf);
|
|
|
|
|
2017-12-15 09:57:55 +08:00
|
|
|
rpcrdma_mrs_create(r_xprt);
|
2019-06-19 22:32:48 +08:00
|
|
|
xprt_write_space(&r_xprt->rx_xprt);
|
2016-06-30 01:54:00 +08:00
|
|
|
}
|
|
|
|
|
2019-10-10 01:07:48 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_mrs_refresh - Wake the MR refresh worker
|
|
|
|
* @r_xprt: controlling transport instance
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
void rpcrdma_mrs_refresh(struct rpcrdma_xprt *r_xprt)
|
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep = r_xprt->rx_ep;
|
2019-10-10 01:07:48 +08:00
|
|
|
|
2020-02-22 06:00:44 +08:00
|
|
|
/* If there is no underlying connection, it's no use
|
|
|
|
* to wake the refresh worker.
|
2019-10-10 01:07:48 +08:00
|
|
|
*/
|
2022-09-19 01:28:16 +08:00
|
|
|
if (ep->re_connect_status != 1)
|
|
|
|
return;
|
|
|
|
queue_work(system_highpri_wq, &buf->rb_refresh_worker);
|
2019-10-10 01:07:48 +08:00
|
|
|
}
|
|
|
|
|
2019-04-24 21:39:05 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_req_create - Allocate an rpcrdma_req object
|
|
|
|
* @r_xprt: controlling r_xprt
|
2019-04-24 21:39:21 +08:00
|
|
|
* @size: initial size, in bytes, of send and receive buffers
|
2019-04-24 21:39:05 +08:00
|
|
|
*
|
|
|
|
* Returns an allocated and fully initialized rpcrdma_req or NULL.
|
|
|
|
*/
|
2022-09-23 21:06:11 +08:00
|
|
|
struct rpcrdma_req *rpcrdma_req_create(struct rpcrdma_xprt *r_xprt,
|
|
|
|
size_t size)
|
2015-01-22 00:03:52 +08:00
|
|
|
{
|
2015-10-25 05:27:43 +08:00
|
|
|
struct rpcrdma_buffer *buffer = &r_xprt->rx_buf;
|
2015-01-22 00:03:52 +08:00
|
|
|
struct rpcrdma_req *req;
|
|
|
|
|
2022-09-23 21:06:37 +08:00
|
|
|
req = kzalloc(sizeof(*req), XPRTRDMA_GFP_FLAGS);
|
2015-01-22 00:03:52 +08:00
|
|
|
if (req == NULL)
|
2019-04-24 21:39:21 +08:00
|
|
|
goto out1;
|
2015-01-22 00:03:52 +08:00
|
|
|
|
2022-09-23 21:06:18 +08:00
|
|
|
req->rl_sendbuf = rpcrdma_regbuf_alloc(size, DMA_TO_DEVICE);
|
2019-04-24 21:39:21 +08:00
|
|
|
if (!req->rl_sendbuf)
|
2020-01-04 00:56:53 +08:00
|
|
|
goto out2;
|
2019-04-24 21:39:21 +08:00
|
|
|
|
2022-09-23 21:06:18 +08:00
|
|
|
req->rl_recvbuf = rpcrdma_regbuf_alloc(size, DMA_NONE);
|
2019-04-24 21:39:21 +08:00
|
|
|
if (!req->rl_recvbuf)
|
2020-01-04 00:56:53 +08:00
|
|
|
goto out3;
|
2019-04-24 21:39:21 +08:00
|
|
|
|
2019-08-20 06:47:10 +08:00
|
|
|
INIT_LIST_HEAD(&req->rl_free_mrs);
|
2018-03-01 04:31:05 +08:00
|
|
|
INIT_LIST_HEAD(&req->rl_registered);
|
2018-12-19 23:59:33 +08:00
|
|
|
spin_lock(&buffer->rb_lock);
|
2015-10-25 05:27:43 +08:00
|
|
|
list_add(&req->rl_all, &buffer->rb_allreqs);
|
2018-12-19 23:59:33 +08:00
|
|
|
spin_unlock(&buffer->rb_lock);
|
2015-01-22 00:03:52 +08:00
|
|
|
return req;
|
2019-04-24 21:39:21 +08:00
|
|
|
|
|
|
|
out3:
|
2020-01-04 00:56:53 +08:00
|
|
|
kfree(req->rl_sendbuf);
|
2019-04-24 21:39:21 +08:00
|
|
|
out2:
|
|
|
|
kfree(req);
|
|
|
|
out1:
|
|
|
|
return NULL;
|
2015-01-22 00:03:52 +08:00
|
|
|
}
|
|
|
|
|
2019-10-10 01:07:27 +08:00
|
|
|
/**
|
2020-01-04 00:56:53 +08:00
|
|
|
* rpcrdma_req_setup - Per-connection instance setup of an rpcrdma_req object
|
2019-10-10 01:07:27 +08:00
|
|
|
* @r_xprt: controlling transport instance
|
2020-01-04 00:56:53 +08:00
|
|
|
* @req: rpcrdma_req object to set up
|
2019-10-10 01:07:27 +08:00
|
|
|
*
|
2020-01-04 00:56:53 +08:00
|
|
|
* Returns zero on success, and a negative errno on failure.
|
|
|
|
*/
|
|
|
|
int rpcrdma_req_setup(struct rpcrdma_xprt *r_xprt, struct rpcrdma_req *req)
|
|
|
|
{
|
|
|
|
struct rpcrdma_regbuf *rb;
|
|
|
|
size_t maxhdrsize;
|
|
|
|
|
|
|
|
/* Compute maximum header buffer size in bytes */
|
|
|
|
maxhdrsize = rpcrdma_fixed_maxsz + 3 +
|
2020-02-22 06:01:05 +08:00
|
|
|
r_xprt->rx_ep->re_max_rdma_segs * rpcrdma_readchunk_maxsz;
|
2020-01-04 00:56:53 +08:00
|
|
|
maxhdrsize *= sizeof(__be32);
|
|
|
|
rb = rpcrdma_regbuf_alloc(__roundup_pow_of_two(maxhdrsize),
|
2022-09-23 21:06:18 +08:00
|
|
|
DMA_TO_DEVICE);
|
2020-01-04 00:56:53 +08:00
|
|
|
if (!rb)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (!__rpcrdma_regbuf_dma_map(r_xprt, rb))
|
|
|
|
goto out_free;
|
|
|
|
|
|
|
|
req->rl_rdmabuf = rb;
|
|
|
|
xdr_buf_init(&req->rl_hdrbuf, rdmab_data(rb), rdmab_length(rb));
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_free:
|
|
|
|
rpcrdma_regbuf_free(rb);
|
|
|
|
out:
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ASSUMPTION: the rb_allreqs list is stable for the duration,
|
2019-10-10 01:07:27 +08:00
|
|
|
* and thus can be walked without holding rb_lock. Eg. the
|
|
|
|
* caller is holding the transport send lock to exclude
|
|
|
|
* device removal or disconnection.
|
|
|
|
*/
|
2020-01-04 00:56:53 +08:00
|
|
|
static int rpcrdma_reqs_setup(struct rpcrdma_xprt *r_xprt)
|
2019-10-10 01:07:27 +08:00
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
|
|
|
struct rpcrdma_req *req;
|
2020-01-04 00:56:53 +08:00
|
|
|
int rc;
|
2019-10-10 01:07:27 +08:00
|
|
|
|
|
|
|
list_for_each_entry(req, &buf->rb_allreqs, rl_all) {
|
2020-01-04 00:56:53 +08:00
|
|
|
rc = rpcrdma_req_setup(r_xprt, req);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
2019-10-10 01:07:27 +08:00
|
|
|
}
|
2020-01-04 00:56:53 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void rpcrdma_req_reset(struct rpcrdma_req *req)
|
|
|
|
{
|
|
|
|
/* Credits are valid for only one connection */
|
|
|
|
req->rl_slot.rq_cong = 0;
|
|
|
|
|
|
|
|
rpcrdma_regbuf_free(req->rl_rdmabuf);
|
|
|
|
req->rl_rdmabuf = NULL;
|
|
|
|
|
|
|
|
rpcrdma_regbuf_dma_unmap(req->rl_sendbuf);
|
|
|
|
rpcrdma_regbuf_dma_unmap(req->rl_recvbuf);
|
2020-08-17 23:19:26 +08:00
|
|
|
|
|
|
|
frwr_reset(req);
|
2020-01-04 00:56:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ASSUMPTION: the rb_allreqs list is stable for the duration,
|
|
|
|
* and thus can be walked without holding rb_lock. Eg. the
|
|
|
|
* caller is holding the transport send lock to exclude
|
|
|
|
* device removal or disconnection.
|
|
|
|
*/
|
|
|
|
static void rpcrdma_reqs_reset(struct rpcrdma_xprt *r_xprt)
|
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
|
|
|
struct rpcrdma_req *req;
|
|
|
|
|
|
|
|
list_for_each_entry(req, &buf->rb_allreqs, rl_all)
|
|
|
|
rpcrdma_req_reset(req);
|
2019-10-10 01:07:27 +08:00
|
|
|
}
|
|
|
|
|
2020-01-04 00:57:09 +08:00
|
|
|
static noinline
|
|
|
|
struct rpcrdma_rep *rpcrdma_rep_create(struct rpcrdma_xprt *r_xprt,
|
|
|
|
bool temp)
|
2015-01-22 00:03:52 +08:00
|
|
|
{
|
2021-04-20 02:02:35 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2015-01-22 00:03:52 +08:00
|
|
|
struct rpcrdma_rep *rep;
|
|
|
|
|
2022-09-23 21:06:37 +08:00
|
|
|
rep = kzalloc(sizeof(*rep), XPRTRDMA_GFP_FLAGS);
|
2015-01-22 00:03:52 +08:00
|
|
|
if (rep == NULL)
|
|
|
|
goto out;
|
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
rep->rr_rdmabuf = rpcrdma_regbuf_alloc(r_xprt->rx_ep->re_inline_recv,
|
2022-09-23 21:06:18 +08:00
|
|
|
DMA_FROM_DEVICE);
|
2019-04-24 21:39:16 +08:00
|
|
|
if (!rep->rr_rdmabuf)
|
2015-01-22 00:03:52 +08:00
|
|
|
goto out_free;
|
2019-06-19 22:33:20 +08:00
|
|
|
|
2020-01-04 00:57:09 +08:00
|
|
|
if (!rpcrdma_regbuf_dma_map(r_xprt, rep->rr_rdmabuf))
|
|
|
|
goto out_free_regbuf;
|
|
|
|
|
2020-11-10 03:39:21 +08:00
|
|
|
rep->rr_cid.ci_completion_id =
|
|
|
|
atomic_inc_return(&r_xprt->rx_ep->re_completion_ids);
|
|
|
|
|
2019-04-24 21:39:16 +08:00
|
|
|
xdr_buf_init(&rep->rr_hdrbuf, rdmab_data(rep->rr_rdmabuf),
|
2017-08-04 02:30:03 +08:00
|
|
|
rdmab_length(rep->rr_rdmabuf));
|
2016-09-15 22:57:49 +08:00
|
|
|
rep->rr_cqe.done = rpcrdma_wc_receive;
|
2015-05-26 23:51:37 +08:00
|
|
|
rep->rr_rxprt = r_xprt;
|
2016-09-15 22:56:51 +08:00
|
|
|
rep->rr_recv_wr.next = NULL;
|
|
|
|
rep->rr_recv_wr.wr_cqe = &rep->rr_cqe;
|
|
|
|
rep->rr_recv_wr.sg_list = &rep->rr_rdmabuf->rg_iov;
|
|
|
|
rep->rr_recv_wr.num_sge = 1;
|
2018-05-05 03:35:20 +08:00
|
|
|
rep->rr_temp = temp;
|
2021-04-20 02:02:35 +08:00
|
|
|
|
|
|
|
spin_lock(&buf->rb_lock);
|
|
|
|
list_add(&rep->rr_all, &buf->rb_all_reps);
|
|
|
|
spin_unlock(&buf->rb_lock);
|
2019-06-19 22:33:20 +08:00
|
|
|
return rep;
|
2015-01-22 00:03:52 +08:00
|
|
|
|
2020-01-04 00:57:09 +08:00
|
|
|
out_free_regbuf:
|
|
|
|
rpcrdma_regbuf_free(rep->rr_rdmabuf);
|
2015-01-22 00:03:52 +08:00
|
|
|
out_free:
|
|
|
|
kfree(rep);
|
|
|
|
out:
|
2019-06-19 22:33:20 +08:00
|
|
|
return NULL;
|
2015-01-22 00:03:52 +08:00
|
|
|
}
|
|
|
|
|
2021-04-25 03:02:28 +08:00
|
|
|
static void rpcrdma_rep_free(struct rpcrdma_rep *rep)
|
2019-08-20 06:48:43 +08:00
|
|
|
{
|
|
|
|
rpcrdma_regbuf_free(rep->rr_rdmabuf);
|
|
|
|
kfree(rep);
|
|
|
|
}
|
|
|
|
|
2021-04-25 03:02:28 +08:00
|
|
|
static void rpcrdma_rep_destroy(struct rpcrdma_rep *rep)
|
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &rep->rr_rxprt->rx_buf;
|
|
|
|
|
|
|
|
spin_lock(&buf->rb_lock);
|
|
|
|
list_del(&rep->rr_all);
|
|
|
|
spin_unlock(&buf->rb_lock);
|
|
|
|
|
|
|
|
rpcrdma_rep_free(rep);
|
|
|
|
}
|
|
|
|
|
2019-08-20 06:48:43 +08:00
|
|
|
static struct rpcrdma_rep *rpcrdma_rep_get_locked(struct rpcrdma_buffer *buf)
|
|
|
|
{
|
|
|
|
struct llist_node *node;
|
|
|
|
|
|
|
|
/* Calls to llist_del_first are required to be serialized */
|
|
|
|
node = llist_del_first(&buf->rb_free_reps);
|
|
|
|
if (!node)
|
|
|
|
return NULL;
|
|
|
|
return llist_entry(node, struct rpcrdma_rep, rr_node);
|
|
|
|
}
|
|
|
|
|
2021-04-20 02:02:47 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_rep_put - Release rpcrdma_rep back to free list
|
|
|
|
* @buf: buffer pool
|
|
|
|
* @rep: rep to release
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
void rpcrdma_rep_put(struct rpcrdma_buffer *buf, struct rpcrdma_rep *rep)
|
2019-08-20 06:48:43 +08:00
|
|
|
{
|
2020-01-04 00:52:22 +08:00
|
|
|
llist_add(&rep->rr_node, &buf->rb_free_reps);
|
|
|
|
}
|
|
|
|
|
2021-04-20 02:02:28 +08:00
|
|
|
/* Caller must ensure the QP is quiescent (RQ is drained) before
|
|
|
|
* invoking this function, to guarantee rb_all_reps is not
|
|
|
|
* changing.
|
|
|
|
*/
|
2020-01-04 00:52:22 +08:00
|
|
|
static void rpcrdma_reps_unmap(struct rpcrdma_xprt *r_xprt)
|
|
|
|
{
|
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
|
|
|
struct rpcrdma_rep *rep;
|
|
|
|
|
2020-01-04 00:57:04 +08:00
|
|
|
list_for_each_entry(rep, &buf->rb_all_reps, rr_all) {
|
2020-01-04 00:52:22 +08:00
|
|
|
rpcrdma_regbuf_dma_unmap(rep->rr_rdmabuf);
|
2021-04-20 02:02:28 +08:00
|
|
|
rep->rr_temp = true; /* Mark this rep for destruction */
|
2020-01-04 00:57:04 +08:00
|
|
|
}
|
2019-08-20 06:48:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rpcrdma_reps_destroy(struct rpcrdma_buffer *buf)
|
|
|
|
{
|
|
|
|
struct rpcrdma_rep *rep;
|
|
|
|
|
2021-04-25 03:02:28 +08:00
|
|
|
spin_lock(&buf->rb_lock);
|
|
|
|
while ((rep = list_first_entry_or_null(&buf->rb_all_reps,
|
|
|
|
struct rpcrdma_rep,
|
|
|
|
rr_all)) != NULL) {
|
|
|
|
list_del(&rep->rr_all);
|
|
|
|
spin_unlock(&buf->rb_lock);
|
|
|
|
|
|
|
|
rpcrdma_rep_free(rep);
|
|
|
|
|
|
|
|
spin_lock(&buf->rb_lock);
|
|
|
|
}
|
|
|
|
spin_unlock(&buf->rb_lock);
|
2019-08-20 06:48:43 +08:00
|
|
|
}
|
|
|
|
|
2019-04-24 21:40:25 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_buffer_create - Create initial set of req/rep objects
|
|
|
|
* @r_xprt: transport instance to (re)initialize
|
|
|
|
*
|
|
|
|
* Returns zero on success, otherwise a negative errno.
|
|
|
|
*/
|
|
|
|
int rpcrdma_buffer_create(struct rpcrdma_xprt *r_xprt)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2015-01-22 00:03:44 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2007-09-11 01:51:18 +08:00
|
|
|
int i, rc;
|
|
|
|
|
2015-10-25 05:27:43 +08:00
|
|
|
buf->rb_bc_srv_max_requests = 0;
|
2016-06-30 01:52:54 +08:00
|
|
|
spin_lock_init(&buf->rb_lock);
|
2017-12-15 09:57:55 +08:00
|
|
|
INIT_LIST_HEAD(&buf->rb_mrs);
|
2019-08-20 06:42:31 +08:00
|
|
|
INIT_LIST_HEAD(&buf->rb_all_mrs);
|
2019-08-20 06:45:37 +08:00
|
|
|
INIT_WORK(&buf->rb_refresh_worker, rpcrdma_mr_refresh_worker);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2015-10-25 05:27:02 +08:00
|
|
|
INIT_LIST_HEAD(&buf->rb_send_bufs);
|
2015-10-25 05:27:43 +08:00
|
|
|
INIT_LIST_HEAD(&buf->rb_allreqs);
|
2020-01-04 00:52:22 +08:00
|
|
|
INIT_LIST_HEAD(&buf->rb_all_reps);
|
2019-04-24 21:39:05 +08:00
|
|
|
|
|
|
|
rc = -ENOMEM;
|
2020-01-04 00:56:37 +08:00
|
|
|
for (i = 0; i < r_xprt->rx_xprt.max_reqs; i++) {
|
2007-09-11 01:51:18 +08:00
|
|
|
struct rpcrdma_req *req;
|
|
|
|
|
2022-09-23 21:06:11 +08:00
|
|
|
req = rpcrdma_req_create(r_xprt,
|
|
|
|
RPCRDMA_V1_DEF_INLINE_SIZE * 2);
|
2019-04-24 21:39:05 +08:00
|
|
|
if (!req)
|
2007-09-11 01:51:18 +08:00
|
|
|
goto out;
|
2017-06-08 23:52:12 +08:00
|
|
|
list_add(&req->rl_list, &buf->rb_send_bufs);
|
2015-10-25 05:27:02 +08:00
|
|
|
}
|
|
|
|
|
2019-08-20 06:48:43 +08:00
|
|
|
init_llist_head(&buf->rb_free_reps);
|
2015-01-22 00:03:52 +08:00
|
|
|
|
2007-09-11 01:51:18 +08:00
|
|
|
return 0;
|
|
|
|
out:
|
|
|
|
rpcrdma_buffer_destroy(buf);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2018-12-19 23:59:33 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_req_destroy - Destroy an rpcrdma_req object
|
|
|
|
* @req: unused object to be destroyed
|
|
|
|
*
|
2019-10-10 01:07:48 +08:00
|
|
|
* Relies on caller holding the transport send lock to protect
|
|
|
|
* removing req->rl_all from buf->rb_all_reqs safely.
|
2018-12-19 23:59:33 +08:00
|
|
|
*/
|
2019-08-20 06:47:10 +08:00
|
|
|
void rpcrdma_req_destroy(struct rpcrdma_req *req)
|
2015-01-22 00:03:52 +08:00
|
|
|
{
|
2019-10-10 01:07:43 +08:00
|
|
|
struct rpcrdma_mr *mr;
|
|
|
|
|
2018-12-19 23:59:33 +08:00
|
|
|
list_del(&req->rl_all);
|
|
|
|
|
2019-10-10 01:07:43 +08:00
|
|
|
while ((mr = rpcrdma_mr_pop(&req->rl_free_mrs))) {
|
|
|
|
struct rpcrdma_buffer *buf = &mr->mr_xprt->rx_buf;
|
|
|
|
|
|
|
|
spin_lock(&buf->rb_lock);
|
|
|
|
list_del(&mr->mr_all);
|
|
|
|
spin_unlock(&buf->rb_lock);
|
|
|
|
|
2021-04-20 02:03:00 +08:00
|
|
|
frwr_mr_release(mr);
|
2019-10-10 01:07:43 +08:00
|
|
|
}
|
2019-08-20 06:47:10 +08:00
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
rpcrdma_regbuf_free(req->rl_recvbuf);
|
|
|
|
rpcrdma_regbuf_free(req->rl_sendbuf);
|
|
|
|
rpcrdma_regbuf_free(req->rl_rdmabuf);
|
2015-01-22 00:03:52 +08:00
|
|
|
kfree(req);
|
|
|
|
}
|
|
|
|
|
2019-10-10 01:07:43 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_mrs_destroy - Release all of a transport's MRs
|
2019-10-10 01:07:48 +08:00
|
|
|
* @r_xprt: controlling transport instance
|
2019-10-10 01:07:43 +08:00
|
|
|
*
|
|
|
|
* Relies on caller holding the transport send lock to protect
|
|
|
|
* removing mr->mr_list from req->rl_free_mrs safely.
|
|
|
|
*/
|
2019-10-10 01:07:48 +08:00
|
|
|
static void rpcrdma_mrs_destroy(struct rpcrdma_xprt *r_xprt)
|
2016-06-30 01:54:00 +08:00
|
|
|
{
|
2019-10-10 01:07:48 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2017-12-15 09:57:55 +08:00
|
|
|
struct rpcrdma_mr *mr;
|
2016-06-30 01:54:00 +08:00
|
|
|
|
2019-10-10 01:07:48 +08:00
|
|
|
cancel_work_sync(&buf->rb_refresh_worker);
|
|
|
|
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_lock(&buf->rb_lock);
|
2019-08-20 06:42:31 +08:00
|
|
|
while ((mr = list_first_entry_or_null(&buf->rb_all_mrs,
|
|
|
|
struct rpcrdma_mr,
|
|
|
|
mr_all)) != NULL) {
|
2019-10-10 01:07:43 +08:00
|
|
|
list_del(&mr->mr_list);
|
2017-12-15 09:57:55 +08:00
|
|
|
list_del(&mr->mr_all);
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_unlock(&buf->rb_lock);
|
xprtrdma: Fix list corruption / DMAR errors during MR recovery
The ro_release_mr methods check whether mr->mr_list is empty.
Therefore, be sure to always use list_del_init when removing an MR
linked into a list using that field. Otherwise, when recovering from
transport failures or device removal, list corruption can result, or
MRs can get mapped or unmapped an odd number of times, resulting in
IOMMU-related failures.
In general this fix is appropriate back to v4.8. However, code
changes since then make it impossible to apply this patch directly
to stable kernels. The fix would have to be applied by hand or
reworked for kernels earlier than v4.16.
Backport guidance -- there are several cases:
- When creating an MR, initialize mr_list so that using list_empty
on an as-yet-unused MR is safe.
- When an MR is being handled by the remote invalidation path,
ensure that mr_list is reinitialized when it is removed from
rl_registered.
- When an MR is being handled by rpcrdma_destroy_mrs, it is removed
from mr_all, but it may still be on an rl_registered list. In
that case, the MR needs to be removed from that list before being
released.
- Other cases are covered by using list_del_init in rpcrdma_mr_pop.
Fixes: 9d6b04097882 ('xprtrdma: Place registered MWs on a ... ')
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2018-05-01 23:37:14 +08:00
|
|
|
|
2021-04-20 02:03:00 +08:00
|
|
|
frwr_mr_release(mr);
|
2019-10-10 01:07:48 +08:00
|
|
|
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_lock(&buf->rb_lock);
|
2016-06-30 01:54:00 +08:00
|
|
|
}
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_unlock(&buf->rb_lock);
|
2016-06-30 01:54:00 +08:00
|
|
|
}
|
|
|
|
|
2018-12-20 00:00:37 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_buffer_destroy - Release all hw resources
|
|
|
|
* @buf: root control block for resources
|
|
|
|
*
|
2019-04-24 21:40:36 +08:00
|
|
|
* ORDERING: relies on a prior rpcrdma_xprt_drain :
|
2018-12-20 00:00:37 +08:00
|
|
|
* - No more Send or Receive completions can occur
|
|
|
|
* - All MRs, reps, and reqs are returned to their free lists
|
|
|
|
*/
|
2007-09-11 01:51:18 +08:00
|
|
|
void
|
|
|
|
rpcrdma_buffer_destroy(struct rpcrdma_buffer *buf)
|
|
|
|
{
|
2019-08-20 06:48:43 +08:00
|
|
|
rpcrdma_reps_destroy(buf);
|
2007-09-11 01:51:18 +08:00
|
|
|
|
2018-12-19 23:59:33 +08:00
|
|
|
while (!list_empty(&buf->rb_send_bufs)) {
|
2015-10-25 05:27:02 +08:00
|
|
|
struct rpcrdma_req *req;
|
2014-05-28 22:32:09 +08:00
|
|
|
|
2018-12-19 23:59:33 +08:00
|
|
|
req = list_first_entry(&buf->rb_send_bufs,
|
|
|
|
struct rpcrdma_req, rl_list);
|
|
|
|
list_del(&req->rl_list);
|
|
|
|
rpcrdma_req_destroy(req);
|
2015-10-25 05:27:02 +08:00
|
|
|
}
|
2007-09-11 01:51:18 +08:00
|
|
|
}
|
|
|
|
|
2017-12-15 09:57:55 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_mr_get - Allocate an rpcrdma_mr object
|
|
|
|
* @r_xprt: controlling transport
|
|
|
|
*
|
|
|
|
* Returns an initialized rpcrdma_mr or NULL if no free
|
|
|
|
* rpcrdma_mr objects are available.
|
|
|
|
*/
|
|
|
|
struct rpcrdma_mr *
|
|
|
|
rpcrdma_mr_get(struct rpcrdma_xprt *r_xprt)
|
2014-07-30 05:24:36 +08:00
|
|
|
{
|
2015-05-26 23:52:06 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2019-08-20 06:44:04 +08:00
|
|
|
struct rpcrdma_mr *mr;
|
2015-05-26 23:52:06 +08:00
|
|
|
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_lock(&buf->rb_lock);
|
2019-08-20 06:44:04 +08:00
|
|
|
mr = rpcrdma_mr_pop(&buf->rb_mrs);
|
2019-08-20 06:47:57 +08:00
|
|
|
spin_unlock(&buf->rb_lock);
|
2017-12-15 09:57:55 +08:00
|
|
|
return mr;
|
2017-12-15 09:58:04 +08:00
|
|
|
}
|
|
|
|
|
2021-05-26 06:43:38 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_reply_put - Put reply buffers back into pool
|
|
|
|
* @buffers: buffer pool
|
|
|
|
* @req: object to return
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
void rpcrdma_reply_put(struct rpcrdma_buffer *buffers, struct rpcrdma_req *req)
|
|
|
|
{
|
|
|
|
if (req->rl_reply) {
|
|
|
|
rpcrdma_rep_put(buffers, req->rl_reply);
|
|
|
|
req->rl_reply = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-05 03:35:20 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_buffer_get - Get a request buffer
|
|
|
|
* @buffers: Buffer pool from which to obtain a buffer
|
2016-09-06 23:22:49 +08:00
|
|
|
*
|
2018-05-05 03:35:20 +08:00
|
|
|
* Returns a fresh rpcrdma_req, or NULL if none are available.
|
2007-09-11 01:51:18 +08:00
|
|
|
*/
|
|
|
|
struct rpcrdma_req *
|
|
|
|
rpcrdma_buffer_get(struct rpcrdma_buffer *buffers)
|
|
|
|
{
|
|
|
|
struct rpcrdma_req *req;
|
2015-05-26 23:52:35 +08:00
|
|
|
|
2015-10-25 05:27:27 +08:00
|
|
|
spin_lock(&buffers->rb_lock);
|
2018-05-05 03:35:31 +08:00
|
|
|
req = list_first_entry_or_null(&buffers->rb_send_bufs,
|
|
|
|
struct rpcrdma_req, rl_list);
|
|
|
|
if (req)
|
|
|
|
list_del_init(&req->rl_list);
|
2015-10-25 05:27:27 +08:00
|
|
|
spin_unlock(&buffers->rb_lock);
|
2015-10-25 05:27:02 +08:00
|
|
|
return req;
|
2007-09-11 01:51:18 +08:00
|
|
|
}
|
|
|
|
|
2018-05-05 03:35:20 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_buffer_put - Put request/reply buffers back into pool
|
2019-06-19 22:33:36 +08:00
|
|
|
* @buffers: buffer pool
|
2018-05-05 03:35:20 +08:00
|
|
|
* @req: object to return
|
|
|
|
*
|
2007-09-11 01:51:18 +08:00
|
|
|
*/
|
2019-06-19 22:33:36 +08:00
|
|
|
void rpcrdma_buffer_put(struct rpcrdma_buffer *buffers, struct rpcrdma_req *req)
|
2007-09-11 01:51:18 +08:00
|
|
|
{
|
2021-05-26 06:43:38 +08:00
|
|
|
rpcrdma_reply_put(buffers, req);
|
2015-10-25 05:27:02 +08:00
|
|
|
|
2015-10-25 05:27:27 +08:00
|
|
|
spin_lock(&buffers->rb_lock);
|
2018-05-05 03:35:20 +08:00
|
|
|
list_add(&req->rl_list, &buffers->rb_send_bufs);
|
2015-10-25 05:27:27 +08:00
|
|
|
spin_unlock(&buffers->rb_lock);
|
2007-09-11 01:51:18 +08:00
|
|
|
}
|
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
/* Returns a pointer to a rpcrdma_regbuf object, or NULL.
|
2015-01-22 00:04:00 +08:00
|
|
|
*
|
|
|
|
* xprtrdma uses a regbuf for posting an outgoing RDMA SEND, or for
|
2016-09-15 22:56:10 +08:00
|
|
|
* receiving the payload of RDMA RECV operations. During Long Calls
|
2018-12-19 23:59:01 +08:00
|
|
|
* or Replies they may be registered externally via frwr_map.
|
2015-01-22 00:04:00 +08:00
|
|
|
*/
|
2019-04-24 21:39:32 +08:00
|
|
|
static struct rpcrdma_regbuf *
|
2022-09-23 21:06:18 +08:00
|
|
|
rpcrdma_regbuf_alloc(size_t size, enum dma_data_direction direction)
|
2015-01-22 00:04:00 +08:00
|
|
|
{
|
|
|
|
struct rpcrdma_regbuf *rb;
|
|
|
|
|
2022-09-23 21:06:37 +08:00
|
|
|
rb = kmalloc(sizeof(*rb), XPRTRDMA_GFP_FLAGS);
|
2019-04-24 21:39:16 +08:00
|
|
|
if (!rb)
|
|
|
|
return NULL;
|
2022-09-23 21:06:37 +08:00
|
|
|
rb->rg_data = kmalloc(size, XPRTRDMA_GFP_FLAGS);
|
2019-04-24 21:39:16 +08:00
|
|
|
if (!rb->rg_data) {
|
|
|
|
kfree(rb);
|
|
|
|
return NULL;
|
|
|
|
}
|
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
|
|
|
rb->rg_device = NULL;
|
2016-09-15 22:56:10 +08:00
|
|
|
rb->rg_direction = direction;
|
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
|
|
|
rb->rg_iov.length = size;
|
2015-01-22 00:04:00 +08:00
|
|
|
return rb;
|
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
|
|
|
}
|
2015-01-22 00:04:00 +08:00
|
|
|
|
2019-04-24 21:39:27 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_regbuf_realloc - re-allocate a SEND/RECV buffer
|
|
|
|
* @rb: regbuf to reallocate
|
|
|
|
* @size: size of buffer to be allocated, in bytes
|
|
|
|
* @flags: GFP flags
|
|
|
|
*
|
|
|
|
* Returns true if reallocation was successful. If false is
|
|
|
|
* returned, @rb is left untouched.
|
|
|
|
*/
|
|
|
|
bool rpcrdma_regbuf_realloc(struct rpcrdma_regbuf *rb, size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
void *buf;
|
|
|
|
|
|
|
|
buf = kmalloc(size, flags);
|
|
|
|
if (!buf)
|
|
|
|
return false;
|
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
rpcrdma_regbuf_dma_unmap(rb);
|
2019-04-24 21:39:27 +08:00
|
|
|
kfree(rb->rg_data);
|
|
|
|
|
|
|
|
rb->rg_data = buf;
|
|
|
|
rb->rg_iov.length = size;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
2019-04-24 21:39:32 +08:00
|
|
|
* __rpcrdma_regbuf_dma_map - DMA-map a regbuf
|
|
|
|
* @r_xprt: controlling transport instance
|
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
|
|
|
* @rb: regbuf to be mapped
|
2019-04-24 21:39:32 +08:00
|
|
|
*
|
|
|
|
* Returns true if the buffer is now DMA mapped to @r_xprt's device
|
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
|
|
|
*/
|
2019-04-24 21:39:32 +08:00
|
|
|
bool __rpcrdma_regbuf_dma_map(struct rpcrdma_xprt *r_xprt,
|
|
|
|
struct rpcrdma_regbuf *rb)
|
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
|
|
|
{
|
2020-02-22 06:01:05 +08:00
|
|
|
struct ib_device *device = r_xprt->rx_ep->re_id->device;
|
2017-04-12 01:23:02 +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
|
|
|
if (rb->rg_direction == DMA_NONE)
|
|
|
|
return false;
|
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
rb->rg_iov.addr = ib_dma_map_single(device, rdmab_data(rb),
|
|
|
|
rdmab_length(rb), rb->rg_direction);
|
2018-12-20 00:00:06 +08:00
|
|
|
if (ib_dma_mapping_error(device, rdmab_addr(rb))) {
|
|
|
|
trace_xprtrdma_dma_maperr(rdmab_addr(rb));
|
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
|
|
|
return false;
|
2018-12-20 00:00:06 +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
|
|
|
|
2017-04-12 01:23:02 +08:00
|
|
|
rb->rg_device = device;
|
2020-02-22 06:01:05 +08:00
|
|
|
rb->rg_iov.lkey = r_xprt->rx_ep->re_pd->local_dma_lkey;
|
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
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
static void rpcrdma_regbuf_dma_unmap(struct rpcrdma_regbuf *rb)
|
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
|
|
|
{
|
2018-02-01 01:34:13 +08:00
|
|
|
if (!rb)
|
|
|
|
return;
|
|
|
|
|
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
|
|
|
if (!rpcrdma_regbuf_is_mapped(rb))
|
|
|
|
return;
|
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
ib_dma_unmap_single(rb->rg_device, rdmab_addr(rb), rdmab_length(rb),
|
|
|
|
rb->rg_direction);
|
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
|
|
|
rb->rg_device = NULL;
|
2015-01-22 00:04:00 +08:00
|
|
|
}
|
|
|
|
|
2019-04-24 21:39:32 +08:00
|
|
|
static void rpcrdma_regbuf_free(struct rpcrdma_regbuf *rb)
|
2015-01-22 00:04:00 +08:00
|
|
|
{
|
2019-04-24 21:39:32 +08:00
|
|
|
rpcrdma_regbuf_dma_unmap(rb);
|
2019-04-24 21:39:16 +08:00
|
|
|
if (rb)
|
|
|
|
kfree(rb->rg_data);
|
2015-08-04 01:03:20 +08:00
|
|
|
kfree(rb);
|
2015-01-22 00:04:00 +08:00
|
|
|
}
|
|
|
|
|
2019-10-10 01:07:38 +08:00
|
|
|
/**
|
|
|
|
* rpcrdma_post_recvs - Refill the Receive Queue
|
|
|
|
* @r_xprt: controlling transport instance
|
2021-04-20 02:02:41 +08:00
|
|
|
* @needed: current credit grant
|
|
|
|
* @temp: mark Receive buffers to be deleted after one use
|
2019-10-10 01:07:38 +08:00
|
|
|
*
|
|
|
|
*/
|
2021-04-20 02:02:41 +08:00
|
|
|
void rpcrdma_post_recvs(struct rpcrdma_xprt *r_xprt, int needed, bool temp)
|
2015-10-25 05:27:43 +08:00
|
|
|
{
|
2018-05-05 03:35:20 +08:00
|
|
|
struct rpcrdma_buffer *buf = &r_xprt->rx_buf;
|
2020-02-22 06:01:05 +08:00
|
|
|
struct rpcrdma_ep *ep = r_xprt->rx_ep;
|
2020-01-04 00:57:09 +08:00
|
|
|
struct ib_recv_wr *wr, *bad_wr;
|
2019-06-19 22:33:26 +08:00
|
|
|
struct rpcrdma_rep *rep;
|
2021-04-20 02:02:41 +08:00
|
|
|
int count, rc;
|
2015-10-25 05:27:43 +08:00
|
|
|
|
2018-10-02 02:26:35 +08:00
|
|
|
rc = 0;
|
|
|
|
count = 0;
|
2019-06-19 22:33:26 +08:00
|
|
|
|
2020-02-22 06:00:54 +08:00
|
|
|
if (likely(ep->re_receive_count > needed))
|
2018-10-02 02:26:35 +08:00
|
|
|
goto out;
|
2020-02-22 06:00:54 +08:00
|
|
|
needed -= ep->re_receive_count;
|
2019-02-12 00:23:54 +08:00
|
|
|
if (!temp)
|
|
|
|
needed += RPCRDMA_MAX_RECV_BATCH;
|
2015-10-25 05:27:43 +08:00
|
|
|
|
2021-04-20 02:02:09 +08:00
|
|
|
if (atomic_inc_return(&ep->re_receiving) > 1)
|
|
|
|
goto out;
|
|
|
|
|
2019-06-19 22:33:26 +08:00
|
|
|
/* fast path: all needed reps can be found on the free list */
|
2018-05-05 03:35:20 +08:00
|
|
|
wr = NULL;
|
|
|
|
while (needed) {
|
2019-08-20 06:48:43 +08:00
|
|
|
rep = rpcrdma_rep_get_locked(buf);
|
2020-01-04 00:52:22 +08:00
|
|
|
if (rep && rep->rr_temp) {
|
|
|
|
rpcrdma_rep_destroy(rep);
|
|
|
|
continue;
|
|
|
|
}
|
2019-06-19 22:33:26 +08:00
|
|
|
if (!rep)
|
2019-08-20 06:48:43 +08:00
|
|
|
rep = rpcrdma_rep_create(r_xprt, temp);
|
2019-06-19 22:33:26 +08:00
|
|
|
if (!rep)
|
2019-04-24 21:39:32 +08:00
|
|
|
break;
|
2015-10-25 05:27:43 +08:00
|
|
|
|
2020-11-10 03:39:21 +08:00
|
|
|
rep->rr_cid.ci_queue_id = ep->re_attr.recv_cq->res.id;
|
2020-01-04 00:57:09 +08:00
|
|
|
trace_xprtrdma_post_recv(rep);
|
2018-05-05 03:35:20 +08:00
|
|
|
rep->rr_recv_wr.next = wr;
|
|
|
|
wr = &rep->rr_recv_wr;
|
|
|
|
--needed;
|
2020-01-04 00:57:09 +08:00
|
|
|
++count;
|
2018-05-05 03:35:20 +08:00
|
|
|
}
|
2019-06-19 22:33:26 +08:00
|
|
|
if (!wr)
|
2018-10-02 02:26:35 +08:00
|
|
|
goto out;
|
2018-05-05 03:35:20 +08:00
|
|
|
|
2020-02-22 06:01:05 +08:00
|
|
|
rc = ib_post_recv(ep->re_id->qp, wr,
|
2018-07-19 00:25:32 +08:00
|
|
|
(const struct ib_recv_wr **)&bad_wr);
|
2018-05-05 03:35:20 +08:00
|
|
|
if (rc) {
|
2021-08-03 02:44:30 +08:00
|
|
|
trace_xprtrdma_post_recvs_err(r_xprt, rc);
|
2019-06-19 22:32:38 +08:00
|
|
|
for (wr = bad_wr; wr;) {
|
2018-05-05 03:35:20 +08:00
|
|
|
struct rpcrdma_rep *rep;
|
|
|
|
|
|
|
|
rep = container_of(wr, struct rpcrdma_rep, rr_recv_wr);
|
2019-06-19 22:32:38 +08:00
|
|
|
wr = wr->next;
|
2021-04-20 02:02:47 +08:00
|
|
|
rpcrdma_rep_put(buf, rep);
|
2018-05-05 03:35:20 +08:00
|
|
|
--count;
|
|
|
|
}
|
|
|
|
}
|
2021-08-03 02:44:24 +08:00
|
|
|
if (atomic_dec_return(&ep->re_receiving) > 0)
|
|
|
|
complete(&ep->re_done);
|
|
|
|
|
|
|
|
out:
|
2021-08-03 02:44:30 +08:00
|
|
|
trace_xprtrdma_post_recvs(r_xprt, count);
|
2020-02-22 06:00:54 +08:00
|
|
|
ep->re_receive_count += count;
|
2019-06-19 22:33:26 +08:00
|
|
|
return;
|
2015-10-25 05:27:43 +08:00
|
|
|
}
|