From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-rdma@vger.kernel.org,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 00/22] convert NFS server to new rdma_rw API
Date: Fri, 13 Jan 2017 12:08:49 -0500 [thread overview]
Message-ID: <20170113170849.GF24709@fieldses.org> (raw)
In-Reply-To: <33FF9D08-075A-4153-ADDA-C460C1A4D93B@oracle.com>
On Fri, Jan 13, 2017 at 11:54:01AM -0500, Chuck Lever wrote:
> Hi Bruce-
>
>
> > On Jan 13, 2017, at 11:42 AM, bfields@fieldses.org wrote:
> >
> > Can you summarize the motivation for the change, for someone (like me)
> > that doesn't know much about RDMA? Or does "significant cleanups" cover
> > it?
>
> Last year, Sagi and Christoph introduced a new set of APIs to the
> RDMA core that enable ULPs like iSER and NFS/RDMA to leave the details
> of certain aspects of operation to the core, instead of all the ULPs
> having to implement the details themselves. Kind of a code refactoring /
> de-duplication.
>
> Then, going forward, fixes and improvements made to the logic behind
> this new API will be available to all ULPs that use the new API.
>
> This series converts the server-side RPC-over-RDMA implementation
> to use the new API.
>
>
> > Are there any regressions? For example, will it still support all the
> > same hardware? Is there any change that will be noticeable to NFS/RDMA
> > users?
>
> All the same hardware is supported. The standing policy for ULPs is
> that they must work with all in-tree HCA drivers and devices.
>
> The goal of this work is that there is no user-visible change in
> functionality or performance.
>
> I know it's a lot to consider, and I'm happy to split up the series
> or individual patches to help review.
Eh, I'll try to do a little, but realistically I'm mainly trusting you
and Christoph, so it's more important that the process work for you.
--b.
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux NFS Mailing List
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v1 00/22] convert NFS server to new rdma_rw API
Date: Fri, 13 Jan 2017 12:08:49 -0500 [thread overview]
Message-ID: <20170113170849.GF24709@fieldses.org> (raw)
In-Reply-To: <33FF9D08-075A-4153-ADDA-C460C1A4D93B-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Fri, Jan 13, 2017 at 11:54:01AM -0500, Chuck Lever wrote:
> Hi Bruce-
>
>
> > On Jan 13, 2017, at 11:42 AM, bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org wrote:
> >
> > Can you summarize the motivation for the change, for someone (like me)
> > that doesn't know much about RDMA? Or does "significant cleanups" cover
> > it?
>
> Last year, Sagi and Christoph introduced a new set of APIs to the
> RDMA core that enable ULPs like iSER and NFS/RDMA to leave the details
> of certain aspects of operation to the core, instead of all the ULPs
> having to implement the details themselves. Kind of a code refactoring /
> de-duplication.
>
> Then, going forward, fixes and improvements made to the logic behind
> this new API will be available to all ULPs that use the new API.
>
> This series converts the server-side RPC-over-RDMA implementation
> to use the new API.
>
>
> > Are there any regressions? For example, will it still support all the
> > same hardware? Is there any change that will be noticeable to NFS/RDMA
> > users?
>
> All the same hardware is supported. The standing policy for ULPs is
> that they must work with all in-tree HCA drivers and devices.
>
> The goal of this work is that there is no user-visible change in
> functionality or performance.
>
> I know it's a lot to consider, and I'm happy to split up the series
> or individual patches to help review.
Eh, I'll try to do a little, but realistically I'm mainly trusting you
and Christoph, so it's more important that the process work for you.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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:[~2017-01-13 17:08 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-07 17:15 [PATCH v1 00/22] convert NFS server to new rdma_rw API Chuck Lever
2017-01-07 17:15 ` Chuck Lever
2017-01-07 17:15 ` [PATCH v1 01/22] svcrdma: Another sendto chunk list parsing update Chuck Lever
2017-01-07 17:15 ` Chuck Lever
2017-01-07 17:15 ` [PATCH v1 02/22] svcrdma: Replace RPCRDMA_SQ_DEPTH_MULT Chuck Lever
2017-01-07 17:15 ` Chuck Lever
2017-01-07 17:15 ` [PATCH v1 03/22] svcrdma: Remove unused sc_dto_q field Chuck Lever
2017-01-07 17:15 ` Chuck Lever
2017-01-07 17:15 ` [PATCH v1 04/22] svcrdma: Combine list fields in struct svc_rdma_op_ctxt Chuck Lever
2017-01-07 17:15 ` Chuck Lever
2017-01-07 17:15 ` [PATCH v1 05/22] svcrdma: Poll CQs in "workqueue" mode Chuck Lever
2017-01-07 17:15 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 06/22] svcrdma: Clean up RPC-over-RDMA Reply header encoder Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 07/22] svcrdma: Clean up RPC-over-RDMA Call header decoder Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 08/22] svcrdma: Introduce local rdma_rw API helpers Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 09/22] svcrdma: Use rdma_rw API in RPC reply path Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 10/22] svcrdma: Backchannel sendto clean up Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 11/22] svcrdma: Clean up RDMA_ERROR path Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:16 ` [PATCH v1 12/22] svcrdma: Reduce size of sge array in struct svc_rdma_op_ctxt Chuck Lever
2017-01-07 17:16 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 13/22] svcrdma: Remove old RDMA Write completion handlers Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 14/22] svcrdma: Remove the req_map cache Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 15/22] svcrdma: Clean up RPC-over-RDMA backchannel reply processing Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:36 ` Trond Myklebust
2017-01-07 17:36 ` Trond Myklebust
2017-01-07 17:17 ` [PATCH v1 16/22] svcrdma: Use generic RDMA R/W API in RPC Call path Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 17/22] svcrdma: Remove unused Read completion handlers Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 18/22] svcrdma: Remove frmr cache Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 19/22] svcrdma: Clean up after converting svc_rdma_recvfrom to rdma_rw API Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:17 ` [PATCH v1 20/22] svcrdma: Clean-up in svc_rdma_post_recv Chuck Lever
2017-01-07 17:17 ` Chuck Lever
2017-01-07 17:18 ` [PATCH v1 21/22] svcrdma: Clean-up svc_rdma_unmap_dma Chuck Lever
2017-01-07 17:18 ` Chuck Lever
2017-01-07 17:18 ` [PATCH v1 22/22] svcrdma: Re-order fields in svc_rdma_op_ctxt Chuck Lever
2017-01-07 17:18 ` Chuck Lever
2017-01-08 14:34 ` [PATCH v1 00/22] convert NFS server to new rdma_rw API Christoph Hellwig
2017-01-08 14:34 ` Christoph Hellwig
2017-01-08 17:19 ` Chuck Lever
2017-01-08 17:19 ` Chuck Lever
2017-01-13 16:42 ` J. Bruce Fields
2017-01-13 16:42 ` J. Bruce Fields
2017-01-13 16:54 ` Chuck Lever
2017-01-13 16:54 ` Chuck Lever
2017-01-13 17:08 ` J. Bruce Fields [this message]
2017-01-13 17:08 ` J. Bruce Fields
2017-01-13 22:04 ` Sagi Grimberg
2017-01-13 22:04 ` Sagi Grimberg
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=20170113170849.GF24709@fieldses.org \
--to=bfields@fieldses.org \
--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.