[RFC] extending splice for copy offloading

[Steve French]

You are right, network bandwidth is not the issue - but we can get
info on the underlying filesystem, and perhaps use the FS info (on
sector size etc.) that David noted to control the size we request -
and the number of credits and variations in response time as hints to
control how many copychunk requests we send at one time.

On Tue, Oct 1, 2013 at 4:05 PM, J. Bruce Fields <bfields at fieldses.org> wrote:
> 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.



-- 
Thanks,

Steve