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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
