@@ -587,12 +587,24 @@ static struct p9_trans_rdma *alloc_rdma(struct p9_rdma_opts *opts)
return rdma;
}
-/* its not clear to me we can do anything after send has been posted */
static int rdma_cancel(struct p9_client *client, struct p9_req_t *req)
{
+ /* Nothing to do here.
+ * We will take care of it (if we have to) in rdma_cancelled()
+ */
return 1;
}
+/* A request has been fully flushed without a reply.
+ * That means we have posted one buffer in excess.
+ */
+static int rdma_cancelled(struct p9_client *client, struct p9_req_t *req)
+{
+ struct p9_trans_rdma *rdma = client->trans;
+ atomic_inc(&rdma->excess_rc);
+ return 0;
+}
+
/**
* trans_create_rdma - Transport method for creating atransport instance
* @client: client instance
@@ -726,6 +738,7 @@ static struct p9_trans_module p9_rdma_trans = {
.close = rdma_close,
.request = rdma_request,
.cancel = rdma_cancel,
+ .cancelled = rdma_cancelled,
};
/**
Take into account posted recv buffers that will never receive their reply. The RDMA code posts a recv buffer for each request that it sends. When a request is flushed, it is possible that this request will never receive a reply, and that one recv buffer will stay unused on the recv queue. It is then possible, if this scenario happens several times, to have the recv queue full, and have the 9pnet_rmda module unable to send new requests. Signed-off-by: Simon Derr <simon.derr@bull.net> --- net/9p/trans_rdma.c | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletions(-)