All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Tucker <tom@opengridcomputing.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Tom Tucker <tom@ogc.us>,
	bfields@fieldses.org, linux-nfs@vger.kernel.org, swise@ogc.us
Subject: Re: [PATCH 4/4] rpcrdma: Fix SQ size calculation when memreg is FRMR
Date: Tue, 03 Aug 2010 21:21:38 -0600	[thread overview]
Message-ID: <4C58DCC2.1050109@opengridcomputing.com> (raw)
In-Reply-To: <1280889614.24669.29.camel@heimdal.trondhjem.org>

Trond Myklebust wrote:
> Hi Tom
>
> On Tue, 2010-08-03 at 11:45 -0500, Tom Tucker wrote:
>   
>> This patch updates the computation to include the worst case situation
>> where three FRMR are required to map a single RPC REQ.
>>
>> Signed-off-by: Tom Tucker <tom@ogc.us>
>> ---
>>
>>  net/sunrpc/xprtrdma/rpc_rdma.c |    2 ++
>>  net/sunrpc/xprtrdma/verbs.c    |   20 ++++++++++++++++----
>>  2 files changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
>> index e5e28d1..2ac3f6e 100644
>> --- a/net/sunrpc/xprtrdma/rpc_rdma.c
>> +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
>> @@ -249,6 +249,8 @@ rpcrdma_create_chunks(struct rpc_rqst *rqst, struct xdr_buf *target,
>>  	req->rl_nchunks = nchunks;
>>  
>>  	BUG_ON(nchunks == 0);
>> +	BUG_ON((r_xprt->rx_ia.ri_memreg_strategy == RPCRDMA_FRMR)
>> +	       && (nchunks > 3));
>>     
>
> Where does the number 3 come from?
>   

The assumption below is based on the premise that there is one chunk for 
the header, one for the pagelist, and one for the tail == 3. I guess I 
should have a comment -- sorry :-\

>   
>>  	/*
>>  	 * finish off header. If write, marshal discrim and nchunks.
>> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
>> index 3bdbd9f..5f4c7b3 100644
>> --- a/net/sunrpc/xprtrdma/verbs.c
>> +++ b/net/sunrpc/xprtrdma/verbs.c
>> @@ -650,10 +650,22 @@ rpcrdma_ep_create(struct rpcrdma_ep *ep, struct rpcrdma_ia *ia,
>>  	ep->rep_attr.cap.max_send_wr = cdata->max_requests;
>>  	switch (ia->ri_memreg_strategy) {
>>  	case RPCRDMA_FRMR:
>> -		/* Add room for frmr register and invalidate WRs */
>> -		ep->rep_attr.cap.max_send_wr *= 3;
>> -		if (ep->rep_attr.cap.max_send_wr > devattr.max_qp_wr)
>> -			return -EINVAL;
>> +		/* Add room for frmr register and invalidate WRs.
>> +		 * 1. FRMR reg WR for head
>> +		 * 2. FRMR invalidate WR for head
>> +		 * 3. FRMR reg WR for pagelist
>> +		 * 4. FRMR invalidate WR for pagelist
>> +		 * 5. FRMR reg WR for tail
>> +		 * 6. FRMR invalidate WR for tail
>> +		 * 7. The RDMA_SEND WR
>> +		 */
>> +		ep->rep_attr.cap.max_send_wr *= 7;
>> +		if (ep->rep_attr.cap.max_send_wr > devattr.max_qp_wr) {
>> +			cdata->max_requests = devattr.max_qp_wr / 7;
>> +			if (!cdata->max_requests)
>> +				return -EINVAL;
>> +			ep->rep_attr.cap.max_send_wr = cdata->max_requests * 7;
>> +		}
>>  		break;
>>  	case RPCRDMA_MEMWINDOWS_ASYNC:
>>  	case RPCRDMA_MEMWINDOWS:
>>
>>     
>
>   


  reply	other threads:[~2010-08-04  3:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-03 16:44 [PATCH 0/4] nfsrdma: Miscellanseous Bug Fixes Tom Tucker
2010-08-03 16:45 ` [PATCH 1/4] xprtrdma: Do not truncate iova_start values in frmr registrations Tom Tucker
2010-08-03 16:45 ` [PATCH 2/4] svcrdma: Change DMA mapping logic to avoid the page_address kernel API Tom Tucker
2010-08-03 16:45 ` [PATCH 3/4] svcrdma: Cleanup DMA unmapping in error paths Tom Tucker
2010-08-03 16:45 ` [PATCH 4/4] rpcrdma: Fix SQ size calculation when memreg is FRMR Tom Tucker
     [not found]   ` <20100803164517.2567.50208.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
2010-08-04  2:40     ` Trond Myklebust
2010-08-04  3:21       ` Tom Tucker [this message]
2010-08-04  2:42 ` [PATCH 0/4] nfsrdma: Miscellanseous Bug Fixes Trond Myklebust
2010-08-04  3:24   ` Tom Tucker
2010-08-04  3:26   ` Tom Tucker

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=4C58DCC2.1050109@opengridcomputing.com \
    --to=tom@opengridcomputing.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=swise@ogc.us \
    --cc=tom@ogc.us \
    /path/to/YOUR_REPLY

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

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