Re: [RFC] extending splice for copy offloading

["J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>]

On Thu, Sep 26, 2013 at 12:22:49PM -0500, Steve French wrote:
> >>> I suppose, but can't the app achieve a nice middle ground by copying the
> >>> file in smaller syscalls?  Avoid bulk data motion back to the client,
> >>> but still get notification every, I dunno, few hundred meg?
> >> Yes.  And if "cp"  could just be switched from a read+write syscall
> >> pair to a single splice syscall using the same buffer size.
> > Will the various magic fs-specific copy operations become inefficient
> > when the range copied is too small?
> 
> Yes - it is much less efficient for the network file system cases when
> copy size is small.   Reasonable minimum is probably at least 1MB.
> Windows will use up to 16MB, but a saner approach to this would base
> the copy chunk size on either response time or on network bandwidth
> for the connection.
> 
> Copy offload has been done for a long time with CIFS/SMB2/SMB3
> protocol (and obviously helps a lot more over the network for file
> copies than locally), but only recently have we added support for this
> in Samba through David Disseldorp's work.   i have kernel patches
> almost ready to post for cifs.ko for the client side to do copy
> offload (cp --reflink) via CopyChunk fsctl over SMB3 which is
> supported by most all servers now.
> 
> Windows clients seem to max out at 16MB chunk size when doing copy
> offload.   I would like to increase chunk size larger than that if
> network bandwidth (returned at mount time in SMB3 on the query network
> interfaces FSCTL) is large enough, and response time is not more than
> 100 (?) milliseconds.

I'm confused--copy offload means no data's going over the network, so
why would network bandwidth be a factor at all?

(Or are you talking about some kind of server-to-server bandwidth?)

--b.