linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Sagi Grimberg <sagig@dev.mellanox.co.il>
Cc: anna.schumaker@netapp.com, linux-rdma@vger.kernel.org,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v3 05/11] xprtrdma: Do not wait if ib_post_send() fails
Date: Tue, 8 Mar 2016 13:03:23 -0500	[thread overview]
Message-ID: <8696EFBA-B7DB-42AC-AB57-C656070F4ED3@oracle.com> (raw)
In-Reply-To: <56DF1186.3030303@dev.mellanox.co.il>


> On Mar 8, 2016, at 12:53 PM, Sagi Grimberg <sagig@dev.mellanox.co.il> wrote:
> 
> 
> 
> On 04/03/2016 18:28, Chuck Lever wrote:
>> If ib_post_send() in ro_unmap_sync() fails, the WRs have not been
>> posted, no completions will fire, and wait_for_completion() will
>> wait forever. Skip the wait in that case.
>> 
>> To ensure the MRs are invalid, disconnect.
> 
> How does that help to ensure that?

I should have said "To ensure the MRs are fenced,"

> The first wr that failed and on will leave the
> corresponding MRs invalid, and the others will be valid
> upon completion.

? This is in the invalidation code, not in the fastreg
code.

When this ib_post_send() fails, I've built a set of
chained LOCAL_INV WRs, but they never get posted. So
there is no WR failure here, the WRs are simply
never posted, and they won't complete or flush.

If the connection is no longer there, the MRs are
fenced from the target. Is there a better recovery in
this case?

I suppose I could reset these MRs instead (that is,
pass them to ib_dereg_mr).


> Disconnecting will move the QP to error state,
> but it's not guaranteed that the wrs that _were_ posted will not
> be executed.

Right, disconnecting is not attempting to knock
down running WRs.

> I'd say this is the opposite of ensuring...



--
Chuck Lever




  reply	other threads:[~2016-03-08 18:03 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 16:27 [PATCH v3 00/11] NFS/RDMA client patches for v4.6 Chuck Lever
2016-03-04 16:27 ` [PATCH v3 01/11] xprtrdma: Clean up unused RPCRDMA_INLINE_PAD_THRESH macro Chuck Lever
2016-03-08 17:48   ` Sagi Grimberg
2016-03-04 16:27 ` [PATCH v3 02/11] xprtrdma: Clean up physical_op_map() Chuck Lever
2016-03-08 17:48   ` Sagi Grimberg
2016-03-04 16:27 ` [PATCH v3 03/11] xprtrdma: Clean up dprintk format string containing a newline Chuck Lever
2016-03-08 17:48   ` Sagi Grimberg
2016-03-04 16:27 ` [PATCH v3 04/11] xprtrdma: Segment head and tail XDR buffers on page boundaries Chuck Lever
2016-03-04 16:28 ` [PATCH v3 05/11] xprtrdma: Do not wait if ib_post_send() fails Chuck Lever
2016-03-08 17:53   ` Sagi Grimberg
2016-03-08 18:03     ` Chuck Lever [this message]
2016-03-09 11:09       ` Sagi Grimberg
2016-03-09 20:47         ` Chuck Lever
2016-03-09 21:40           ` Anna Schumaker
2016-03-10 10:25           ` Sagi Grimberg
2016-03-10 15:04             ` Steve Wise
2016-03-10 15:05               ` Chuck Lever
2016-03-10 15:31                 ` Steve Wise
2016-03-10 15:35                   ` Chuck Lever
2016-03-10 15:54                     ` Steve Wise
2016-03-10 15:58                       ` Chuck Lever
2016-03-10 16:10                         ` Steve Wise
2016-03-10 16:14                           ` Chuck Lever
2016-03-10 16:21                             ` Steve Wise
2016-03-10 16:40             ` Chuck Lever
2016-03-10 17:01               ` Anna Schumaker
2016-03-04 16:28 ` [PATCH v3 06/11] rpcrdma: Add RPCRDMA_HDRLEN_ERR Chuck Lever
2016-03-08 17:53   ` Sagi Grimberg
2016-03-04 16:28 ` [PATCH v3 07/11] xprtrdma: Properly handle RDMA_ERROR replies Chuck Lever
2016-03-04 16:28 ` [PATCH v3 08/11] xprtrdma: Serialize credit accounting again Chuck Lever
2016-03-04 16:28 ` [PATCH v3 09/11] xprtrdma: Use new CQ API for RPC-over-RDMA client receive CQs Chuck Lever
2016-03-08 17:55   ` Sagi Grimberg
2016-03-04 16:28 ` [PATCH v3 10/11] xprtrdma: Use an anonymous union in struct rpcrdma_mw Chuck Lever
2016-03-08 17:55   ` Sagi Grimberg
2016-03-04 16:28 ` [PATCH v3 11/11] xprtrdma: Use new CQ API for RPC-over-RDMA client send CQs Chuck Lever

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=8696EFBA-B7DB-42AC-AB57-C656070F4ED3@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sagig@dev.mellanox.co.il \
    /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;
as well as URLs for NNTP newsgroup(s).