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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v5 00/14] NFS/RDMA server patches for v4.6
Date: Wed, 2 Mar 2016 14:01:34 -0500 [thread overview]
Message-ID: <20160302190134.GB3512@fieldses.org> (raw)
In-Reply-To: <A6015E74-BB21-47EE-B100-0C5DC0C67591-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Wed, Mar 02, 2016 at 10:36:42AM -0800, Chuck Lever wrote:
>
> > On Mar 1, 2016, at 2:00 PM, J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:
> >
> >> On Tue, Mar 01, 2016 at 01:05:14PM -0500, Chuck Lever wrote:
> >> Hi Bruce-
> >>
> >> I think these are ready for linux-next.
> >
> > OK, applying for 4.6, thanks.
>
> Thanks!
>
> > I still wonder whether the code makes incorrect assumptions about how
> > the server xdr encoder uses the reply xdr_buf.
>
> Assumptions, probably. I believe these assumptions are the same as are
> made on the client side. It would be awesome to build an API contract
> for struct xdr_buf and have it written down somewhere, then we would
> know for sure.
>
>
> > That might only affect
> > clients which constructed rather strange compounds. And shouldn't be
> > made any worse by these patches.
>
> You're thinking of clients that might send more than one READ or WRITE
> in and NFSv4 COMPOUND? The thought for the current implementation
> is that the first READ or WRITE operation would be allowed to use the
> xdr_buf page list, and arguments/results for the remaining READ/WRITE
> operations would go inline (ie: a Long Call or Reply with data copy on
> both ends).
Actually once the server realizes a compound is "too complicated" (e.g.,
more than one READ), it just reverts to encoding into the head till it's
full, then the first page, then the second, etc., with no special
treatment for read data. (Grep for RQ_SPLICE_OK, especially in
fs/nfsd/nfs4xdr.c).
--b.
--
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
prev parent reply other threads:[~2016-03-02 19:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 18:05 [PATCH v5 00/14] NFS/RDMA server patches for v4.6 Chuck Lever
[not found] ` <20160301180337.2492.4255.stgit-Hs+gFlyCn65vLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-03-01 18:05 ` [PATCH v5 01/14] nfsd: Update NFS server comments related to RDMA support Chuck Lever
2016-03-01 18:05 ` [PATCH v5 02/14] svcrdma: Find client-provided write and reply chunks once per reply Chuck Lever
2016-03-01 18:05 ` [PATCH v5 03/14] svcrdma: Do not write xdr_buf::tail in a Write chunk Chuck Lever
2016-03-01 18:05 ` [PATCH v5 04/14] svcrdma: Do not send Write chunk XDR pad with inline content Chuck Lever
2016-03-01 18:06 ` [PATCH v5 05/14] nfsd: Lower NFSv4.1 callback message size limit Chuck Lever
2016-03-01 18:06 ` [PATCH v5 06/14] svcrdma: Close connection when a send error occurs Chuck Lever
2016-03-01 18:06 ` [PATCH v5 07/14] svcrdma: svc_rdma_post_recv() should close connection on error Chuck Lever
2016-03-01 18:06 ` [PATCH v5 08/14] rpcrdma: Add RPCRDMA_HDRLEN_ERR Chuck Lever
2016-03-01 18:06 ` [PATCH v5 09/14] svcrdma: Make RDMA_ERROR messages work Chuck Lever
2016-03-01 18:06 ` [PATCH v5 10/14] svcrdma: Use correct XID in error replies Chuck Lever
2016-03-01 18:06 ` [PATCH v5 11/14] svcrdma: Hook up the logic to return ERR_CHUNK Chuck Lever
2016-03-01 18:07 ` [PATCH v5 12/14] svcrdma: Remove close_out exit path Chuck Lever
2016-03-01 18:07 ` [PATCH v5 13/14] svcrdma: Use new CQ API for RPC-over-RDMA server receive CQs Chuck Lever
2016-03-01 18:07 ` [PATCH v5 14/14] svcrdma: Use new CQ API for RPC-over-RDMA server send CQs Chuck Lever
2016-03-01 22:00 ` [PATCH v5 00/14] NFS/RDMA server patches for v4.6 J. Bruce Fields
[not found] ` <20160301220052.GF23792-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2016-03-02 18:36 ` Chuck Lever
[not found] ` <A6015E74-BB21-47EE-B100-0C5DC0C67591-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-03-02 19:01 ` J. Bruce Fields [this message]
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=20160302190134.GB3512@fieldses.org \
--to=bfields-uc3wqj2krung9huczpvpmw@public.gmane.org \
--cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox