Return-Path: linux-nfs-owner@vger.kernel.org Received: from fieldses.org ([174.143.236.118]:49480 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750974Ab3FQOed (ORCPT ); Mon, 17 Jun 2013 10:34:33 -0400 Date: Mon, 17 Jun 2013 10:34:26 -0400 From: "J. Bruce Fields" To: "Myklebust, Trond" Cc: Jeff Layton , Sandeep Joshi , "linux-nfs@vger.kernel.org" Subject: Re: why does nfsd write not use splice Message-ID: <20130617143426.GA27193@fieldses.org> References: <20130611195140.GA29634@fieldses.org> <51B7DE9C.6080703@talpey.com> <20130612153936.GB32569@fieldses.org> <20130612164637.GA6868@fieldses.org> <20130614152215.1f369a4c@tlielax.poochiereds.net> <4FA345DA4F4AE44899BD2B03EEEC2FA93F403977@durexcmbx02-prd.hq.netapp.com> <20130617070115.34b2fabb@corrin.poochiereds.net> <58D5D77A-B341-4632-A61D-A13462CD40E7@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <58D5D77A-B341-4632-A61D-A13462CD40E7@netapp.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mon, Jun 17, 2013 at 11:48:18AM +0000, Myklebust, Trond wrote: > > On Jun 17, 2013, at 7:01 AM, Jeff Layton wrote: > > Encryption certainly can be a problem, but integrity isn't > > necessarily one. > > > > Basically the idea would be to receive the data off the socket into > > a set of pages and then splice those into the correct spot in the > > local file. In both the privacy and integrity cases, you just have > > an extra step in between. Privacy *may* mean an extra copy too > > (though some of the crypto routines can decrypt data in place), but > > handling integrity shouldn't. > > > > The tricky parts (I think) are determining how to lay out the > > received data into the pages you eventually want to splice into the > > file before you receive that data in, and how to deal with it when > > the WRITE doesn't cover an entire page. > > Once you've copied the data one time, most of the advantage of > splice() is gone, since a copy will then exist in processor cache > memory and can be duplicated quickly. Well, worst case you could turn it off in krb5i/krb5p cases and maybe still get some benefit in the auth_sys case? I suspect it will be a fair amount of work just to get enough of a prototype up that you can start to measure the benefit (if any). So this isn't going to happen without someone pretty committed to the idea. (And such a person would be better off starting by describing the actual probem they're trying to solve before jumping to the conclusion that splice is the solution.) --b.