From: Shirley Ma <shirley.ma@oracle.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-rdma <linux-rdma@vger.kernel.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 10/13] xprtrdma: Release FRMR segment buffers during LOCAL_INV completion
Date: Wed, 25 Jun 2014 09:14:38 -0700 [thread overview]
Message-ID: <53AAF56E.7010800@oracle.com> (raw)
In-Reply-To: <89930B1D-AE3B-48AD-922C-6FCA754D2B01@oracle.com>
On 06/25/2014 07:32 AM, Chuck Lever wrote:
> Hi Shirley-
>
> On Jun 25, 2014, at 1:17 AM, Shirley Ma <shirley.ma@oracle.com> wrote:
>
>> Would it be possible to delay rpcrdma_buffer_put() until LOCAL_INV request send completion? remove rpcrdma_buffer_put() from xprt_rdma_free(), add a call back after LOCAL_INV completed?
>
> That’s exactly what this patch does. The relevant part of
> rpcrdma_buffer_put() is:
>
> list_add(&mw->mw_list, &buf->rb_mws);
>
> This is now wrapped with a reference count so that
> rpcrdma_buffer_put() and the LOCAL_INV completion can run in any
> order. The FRMR is added back to the list only after both of those
> two have finished.
What I was thinking is to run rpcrdma_buffer_put after LOCAL_INV completion without reference count.
> Nothing in xprt_rdma_free() is allowed to sleep, so we can’t wait for
> LOCAL_INV completion in there.
>
> The only alternative I can think of is having rpcrdma_buffer_get() check
> fr_state as it removes FRMRs from the rb_mws list. Only if the FRMR is
> marked FRMR_IS_INVALID, rpcrdma_buffer_get() will add it to the
> rpcrdma_req.
I thought about it too, an atomic operation would be better than a lock.
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Shirley Ma <shirley.ma-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux NFS Mailing List
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v1 10/13] xprtrdma: Release FRMR segment buffers during LOCAL_INV completion
Date: Wed, 25 Jun 2014 09:14:38 -0700 [thread overview]
Message-ID: <53AAF56E.7010800@oracle.com> (raw)
In-Reply-To: <89930B1D-AE3B-48AD-922C-6FCA754D2B01-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On 06/25/2014 07:32 AM, Chuck Lever wrote:
> Hi Shirley-
>
> On Jun 25, 2014, at 1:17 AM, Shirley Ma <shirley.ma-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
>> Would it be possible to delay rpcrdma_buffer_put() until LOCAL_INV request send completion? remove rpcrdma_buffer_put() from xprt_rdma_free(), add a call back after LOCAL_INV completed?
>
> That’s exactly what this patch does. The relevant part of
> rpcrdma_buffer_put() is:
>
> list_add(&mw->mw_list, &buf->rb_mws);
>
> This is now wrapped with a reference count so that
> rpcrdma_buffer_put() and the LOCAL_INV completion can run in any
> order. The FRMR is added back to the list only after both of those
> two have finished.
What I was thinking is to run rpcrdma_buffer_put after LOCAL_INV completion without reference count.
> Nothing in xprt_rdma_free() is allowed to sleep, so we can’t wait for
> LOCAL_INV completion in there.
>
> The only alternative I can think of is having rpcrdma_buffer_get() check
> fr_state as it removes FRMRs from the rb_mws list. Only if the FRMR is
> marked FRMR_IS_INVALID, rpcrdma_buffer_get() will add it to the
> rpcrdma_req.
I thought about it too, an atomic operation would be better than a lock.
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-06-25 16:14 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 22:39 [PATCH v1 00/13] NFS/RDMA patches for 3.17 Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-23 22:39 ` [PATCH v1 01/13] xprtrdma: Fix panic in rpcrdma_register_frmr_external() Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-24 14:37 ` Or Gerlitz
2014-06-24 14:37 ` Or Gerlitz
2014-06-23 22:39 ` [PATCH v1 02/13] xprtrdma: Protect ->qp during FRMR deregistration Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-23 22:39 ` [PATCH v1 03/13] xprtrdma: Limit data payload size for ALLPHYSICAL Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-23 22:39 ` [PATCH v1 04/13] xprtrdma: Update rkeys after transport reconnect Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-23 22:39 ` [PATCH v1 05/13] xprtrdma: Don't drain CQs on transport disconnect Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-07-02 19:06 ` Devesh Sharma
2014-07-02 19:06 ` Devesh Sharma
2014-07-02 19:28 ` Steve Wise
2014-07-02 19:28 ` Steve Wise
2014-07-02 19:40 ` Chuck Lever
2014-07-02 19:40 ` Chuck Lever
2014-07-02 19:46 ` Steve Wise
2014-07-02 19:46 ` Steve Wise
2014-07-02 19:48 ` Devesh Sharma
2014-07-02 19:48 ` Devesh Sharma
2014-07-02 19:59 ` Chuck Lever
2014-07-02 19:59 ` Chuck Lever
2014-07-03 5:33 ` Devesh Sharma
2014-07-03 5:33 ` Devesh Sharma
2014-07-02 19:42 ` Devesh Sharma
2014-07-02 19:42 ` Devesh Sharma
2014-07-02 19:50 ` Steve Wise
2014-07-02 19:50 ` Steve Wise
2014-07-02 19:53 ` Devesh Sharma
2014-07-02 19:53 ` Devesh Sharma
2014-07-02 19:56 ` Steve Wise
2014-07-02 19:56 ` Steve Wise
2014-07-02 19:57 ` Devesh Sharma
2014-07-02 19:57 ` Devesh Sharma
2014-07-02 19:56 ` Devesh Sharma
2014-07-02 19:56 ` Devesh Sharma
2014-06-23 22:39 ` [PATCH v1 06/13] xprtrdma: Unclutter struct rpcrdma_mr_seg Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-23 22:39 ` [PATCH v1 07/13] xprtrdma: Encode Work Request opcode in wc->wr_id Chuck Lever
2014-06-23 22:39 ` Chuck Lever
2014-06-23 22:40 ` [PATCH v1 08/13] xprtrdma: Back off rkey when FAST_REG_MR fails Chuck Lever
2014-06-23 22:40 ` Chuck Lever
2014-06-24 15:47 ` Anna Schumaker
2014-06-24 15:47 ` Anna Schumaker
2014-06-24 16:26 ` Chuck Lever
2014-06-24 16:26 ` Chuck Lever
2014-06-23 22:40 ` [PATCH v1 09/13] xprtrdma: Refactor rpcrdma_buffer_put() Chuck Lever
2014-06-23 22:40 ` Chuck Lever
2014-06-23 22:40 ` [PATCH v1 10/13] xprtrdma: Release FRMR segment buffers during LOCAL_INV completion Chuck Lever
2014-06-23 22:40 ` Chuck Lever
2014-06-25 5:17 ` Shirley Ma
2014-06-25 5:17 ` Shirley Ma
2014-06-25 14:32 ` Chuck Lever
2014-06-25 14:32 ` Chuck Lever
2014-06-25 16:14 ` Shirley Ma [this message]
2014-06-25 16:14 ` Shirley Ma
2014-06-23 22:40 ` [PATCH v1 11/13] xprtrdma: Clean up rpcrdma_ep_disconnect() Chuck Lever
2014-06-23 22:40 ` Chuck Lever
2014-06-23 22:40 ` [PATCH v1 12/13] xprtrdma: Remove RPCRDMA_PERSISTENT_REGISTRATION macro Chuck Lever
2014-06-23 22:40 ` Chuck Lever
2014-06-23 22:40 ` [PATCH v1 13/13] xprtrdma: Handle additional connection events Chuck Lever
2014-06-23 22:40 ` Chuck Lever
2014-06-24 15:58 ` Anna Schumaker
2014-06-24 15:58 ` Anna Schumaker
2014-06-24 14:35 ` [PATCH v1 00/13] NFS/RDMA patches for 3.17 Or Gerlitz
2014-06-24 14:35 ` Or Gerlitz
2014-06-24 17:07 ` Chuck Lever
2014-06-24 17:07 ` Chuck Lever
2014-06-25 22:47 ` Steve Wise
2014-06-25 22:47 ` Steve Wise
2014-06-27 16:17 ` Shirley Ma
2014-06-27 16:17 ` Shirley Ma
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=53AAF56E.7010800@oracle.com \
--to=shirley.ma@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/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.