From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: [RFC] extending splice for copy offloading Date: Thu, 26 Sep 2013 17:23:51 -0400 Message-ID: <5244A5E7.90808@redhat.com> References: <1378919210-10372-1-git-send-email-zab@redhat.com> <20130925183828.GA30372@lenny.home.zabbo.net> <20130925190620.GB30372@lenny.home.zabbo.net> <20130925195526.GA18971@fieldses.org> <20130925210742.GG30372@lenny.home.zabbo.net> <20130926153359.GE704@fieldses.org> <20130926190611.GP30372@lenny.home.zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Zach Brown , "J. Bruce Fields" , Anna Schumaker , Kernel Mailing List , Linux-Fsdevel , "linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Trond Myklebust , Bryan Schumaker , "Martin K. Petersen" , Jens Axboe , Mark Fasheh , Joel Becker , Eric Wong To: Miklos Szeredi Return-path: In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On 09/26/2013 03:53 PM, Miklos Szeredi wrote: > On Thu, Sep 26, 2013 at 9:06 PM, Zach Brown wrote: > >>> But I'm not sure it's worth the effort; 99% of the use of this >>> interface will be copying whole files. And for that perhaps we need a >>> different API, one which has been discussed some time ago: >>> asynchronous copyfile() returns immediately with a pollable event >>> descriptor indicating copy progress, and some way to cancel the copy. >>> And that can internally rely on ->direct_splice(), with appropriate >>> algorithms for determine the optimal chunk size. >> And perhaps we don't. Perhaps we can provide this much simpler >> data-plane interface that works well enough for most everyone and can >> avoid going down the async rat hole, yet again. > I think either buffering or async is needed to get good perforrmace > without too much complexity in the app (which is not good). Buffering > works quite well for regular I/O, so maybe its the way to go here as > well. > > Thanks, > Miklos > Buffering misses the whole point of the copy offload - the idea is *not* to read or write the actual data in the most interesting cases which offload the operation to a smart target device or file system. Regards, Ric -- 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