Linux NFS development
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Tom Talpey <talpey@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 05/15] RPC/RDMA: fix connection IRD/ORD setting
Date: Wed, 08 Oct 2008 13:26:56 -0400	[thread overview]
Message-ID: <1223486816.7361.12.camel@localhost> (raw)
In-Reply-To: <20081008154744.1336.20909.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>

On Wed, 2008-10-08 at 11:47 -0400, Tom Talpey wrote:
> From: Tom Tucker <talpey@netapp.com>

Now I'm really confused!

> This logic sets the connection parameter that configures the local device
> and informs the remote peer how many concurrent incoming RDMA_READ
> requests are supported. The original logic didn't really do what was
> intended for two reasons:
> 
> - The max number supported by the device is typically smaller than
> any one factor in the calculation used, and
> 
> - The field in the connection parameter structure where the value is
> stored is a u8 and always overflows for the default settings.
> 
> So what really happens is the value requested for responder resources
> is the left over 8 bits from the "desired value". If the desired value
> happened to be a multiple of 256, the result was zero and it wouldn't
> connect at all.
> 
> Given the above and the fact that max_requests is almost always larger
> than the max responder resources supported by the adapter, this patch
> simplifies this logic and simply requests the max supported by the device,
> subject to a reasonable limit.
> 
> This bug was found by Jim Schutt at Sandia.
> 
> Signed-off-by: Tom Tucker <tom@opengridcomputing.com>
> Signed-off-by: Tom Talpey <talpey@netapp.com>
> ---
> 
>  net/sunrpc/xprtrdma/verbs.c |   51 ++++++++++++-------------------------------
>  1 files changed, 14 insertions(+), 37 deletions(-)
> 
> diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
> index 39a1652..e3fe905 100644
> --- a/net/sunrpc/xprtrdma/verbs.c
> +++ b/net/sunrpc/xprtrdma/verbs.c
> @@ -705,30 +705,13 @@ rpcrdma_ep_create(struct rpcrdma_ep *ep, struct rpcrdma_ia *ia,
>  	ep->rep_remote_cma.private_data_len = 0;
>  
>  	/* Client offers RDMA Read but does not initiate */
> -	switch (ia->ri_memreg_strategy) {
> -	case RPCRDMA_BOUNCEBUFFERS:
> +	ep->rep_remote_cma.initiator_depth = 0;
> +	if (ia->ri_memreg_strategy == RPCRDMA_BOUNCEBUFFERS)
>  		ep->rep_remote_cma.responder_resources = 0;
> -		break;
> -	case RPCRDMA_MTHCAFMR:
> -	case RPCRDMA_REGISTER:
> -	case RPCRDMA_FRMR:
> -		ep->rep_remote_cma.responder_resources = cdata->max_requests *
> -				(RPCRDMA_MAX_DATA_SEGS / 8);
> -		break;
> -	case RPCRDMA_MEMWINDOWS:
> -	case RPCRDMA_MEMWINDOWS_ASYNC:
> -#if RPCRDMA_PERSISTENT_REGISTRATION
> -	case RPCRDMA_ALLPHYSICAL:
> -#endif
> -		ep->rep_remote_cma.responder_resources = cdata->max_requests *
> -				(RPCRDMA_MAX_DATA_SEGS / 2);
> -		break;
> -	default:
> -		break;
> -	}
> -	if (ep->rep_remote_cma.responder_resources > devattr.max_qp_rd_atom)
> +	else if (devattr.max_qp_rd_atom > 32)	/* arbitrary but <= 255 */
> +		ep->rep_remote_cma.responder_resources = 32;
> +	else
>  		ep->rep_remote_cma.responder_resources = devattr.max_qp_rd_atom;
> -	ep->rep_remote_cma.initiator_depth = 0;
>  
>  	ep->rep_remote_cma.retry_count = 7;
>  	ep->rep_remote_cma.flow_control = 0;
> @@ -858,14 +841,6 @@ if (strnicmp(ia->ri_id->device->dma_device->bus->name, "pci", 3) == 0) {
>  	}
>  }
>  
> -	/* Theoretically a client initiator_depth > 0 is not needed,
> -	 * but many peers fail to complete the connection unless they
> -	 * == responder_resources! */
> -	if (ep->rep_remote_cma.initiator_depth !=
> -				ep->rep_remote_cma.responder_resources)
> -		ep->rep_remote_cma.initiator_depth =
> -			ep->rep_remote_cma.responder_resources;
> -
>  	ep->rep_connected = 0;
>  
>  	rc = rdma_connect(ia->ri_id, &ep->rep_remote_cma);
> @@ -894,14 +869,16 @@ if (strnicmp(ia->ri_id->device->dma_device->bus->name, "pci", 3) == 0) {
>  	if (ep->rep_connected <= 0) {
>  		/* Sometimes, the only way to reliably connect to remote
>  		 * CMs is to use same nonzero values for ORD and IRD. */
> -		ep->rep_remote_cma.initiator_depth =
> -					ep->rep_remote_cma.responder_resources;
> -		if (ep->rep_remote_cma.initiator_depth == 0)
> -			++ep->rep_remote_cma.initiator_depth;
> -		if (ep->rep_remote_cma.responder_resources == 0)
> -			++ep->rep_remote_cma.responder_resources;
> -		if (retry_count++ == 0)
> +		if (retry_count++ <= RDMA_CONNECT_RETRY_MAX + 1 &&
> +		    (ep->rep_remote_cma.responder_resources == 0 ||
> +		     ep->rep_remote_cma.initiator_depth !=
> +				ep->rep_remote_cma.responder_resources)) {
> +			if (ep->rep_remote_cma.responder_resources == 0)
> +				ep->rep_remote_cma.responder_resources = 1;
> +			ep->rep_remote_cma.initiator_depth =
> +				ep->rep_remote_cma.responder_resources;
>  			goto retry;
> +		}
>  		rc = ep->rep_connected;
>  	} else {
>  		dprintk("RPC:       %s: connected\n", __func__);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  parent reply	other threads:[~2008-10-08 17:27 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-08 15:46 [PATCH 00/15] RPC/RDMA patchset for next merge window Tom Talpey
     [not found] ` <20081008154506.1336.59892.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 15:47   ` [PATCH 01/15] RPC/RDMA: refactor the inline memory registration code Tom Talpey
2008-10-08 15:47   ` [PATCH 02/15] RPC/RDMA: add data types and new FRMR memory registration enum Tom Talpey
     [not found]     ` <20081008154713.1336.41538.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 17:23       ` Trond Myklebust
2008-10-08 17:30         ` Talpey, Thomas
     [not found]           ` <RTPCLUEXC1-PRDmcarc00000072-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-08 17:40             ` Trond Myklebust
2008-10-08 17:55             ` J. Bruce Fields
2008-10-08 17:58               ` Talpey, Thomas
2008-10-08 15:47   ` [PATCH 03/15] RPC/RDMA: check selected memory registration mode at runtime Tom Talpey
     [not found]     ` <20081008154723.1336.57976.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 17:22       ` Trond Myklebust
2008-10-08 17:29         ` Talpey, Thomas
     [not found]           ` <RTPCLUEXC1-PRD8yfog00000071-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-08 17:40             ` Trond Myklebust
2008-10-08 15:47   ` [PATCH 04/15] RPC/RDMA: support FRMR client memory registration Tom Talpey
2008-10-08 15:47   ` [PATCH 05/15] RPC/RDMA: fix connection IRD/ORD setting Tom Talpey
     [not found]     ` <20081008154744.1336.20909.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 17:26       ` Trond Myklebust [this message]
2008-10-08 17:32         ` Talpey, Thomas
2008-10-08 15:47   ` [PATCH 06/15] RPC/RDMA: suppress retransmit on RPC/RDMA clients Tom Talpey
2008-10-08 15:48   ` [PATCH 07/15] RPC/RDMA: maintain the RPC task bytes-sent statistic Tom Talpey
2008-10-08 15:48   ` [PATCH 08/15] RPC/RDMA: avoid an oops due to disconnect racing with async upcalls Tom Talpey
2008-10-08 15:48   ` [PATCH 09/15] RPC/RDMA: adhere to protocol for unpadded client trailing write chunks Tom Talpey
     [not found]     ` <20081008154825.1336.79549.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 17:29       ` Trond Myklebust
2008-10-08 17:33         ` Talpey, Thomas
2008-10-08 15:48   ` [PATCH 10/15] RPC/RDMA: return a consistent error to mount, when connect fails Tom Talpey
     [not found]     ` <20081008154835.1336.85484.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 17:31       ` Trond Myklebust
2008-10-08 17:40         ` Talpey, Thomas
     [not found]           ` <RTPCLUEXC1-PRDbpH7100000075-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-08 17:43             ` Trond Myklebust
2008-10-08 19:56               ` Talpey, Thomas
2008-10-08 15:48   ` [PATCH 11/15] RPC/RDMA: fix connect/reconnect resource leak Tom Talpey
2008-10-08 15:48   ` [PATCH 12/15] RPC/RDMA: correct a 5 second pause on reconnecting to an idle server Tom Talpey
     [not found]     ` <20081008154856.1336.18339.stgit-pfX4bTJKMULWwzOYslWYilaTQe2KTcn/@public.gmane.org>
2008-10-08 17:35       ` Trond Myklebust
2008-10-08 17:51         ` Talpey, Thomas
     [not found]           ` <RTPCLUEXC1-PRDjbDt300000076-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-10-08 18:04             ` Trond Myklebust
2008-10-08 19:05               ` Talpey, Thomas
2008-10-08 15:49   ` [PATCH 13/15] RPC/RDMA: harden connection logic against missing/late rdma_cm upcalls Tom Talpey
2008-10-08 15:49   ` [PATCH 14/15] RPC/RDMA: reformat a debug printk to keep lines together Tom Talpey
2008-10-08 15:49   ` [PATCH 15/15] RPC/RDMA: optionally emit useful transport info upon connect/disconnect Tom Talpey

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=1223486816.7361.12.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-nfs@vger.kernel.org \
    --cc=talpey@netapp.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox