[RFC] extending splice for copy offloading

[Zach Brown]

When I first started on this stuff I followed the lead of previous
work and added a new syscall for the copy operation:

https://lkml.org/lkml/2013/5/14/618

Towards the end of that thread Eric Wong asked why we didn't just
extend splice.  I immediately replied with some dumb dismissive
answer.  Once I sat down and looked at it, though, it does make a
lot of sense.  So good job, Eric.  +10 Dummie points for me.

Extending splice avoids all the noise of adding a new syscall and
naturally falls back to buffered copying as that's what the direct
splice path does for sendfile() today.

So that's what this patch series demonstrates.  It adds a flag that
lets splice get at the same direct splicing that sendfile() does.
We then add a file system file_operations method to accelerate the
copy which has access to both files.

Some things to talk about:
- I really don't care about the naming here.  If you do, holler.
- We might want different flags for file-to-file splicing and acceleration
- We might want flags to require or forbid acceleration
- We might want to provide all these flags to sendfile, too

Thoughts?  Objections?

Bryan, do you see any problems with wiring the NFS COPY RPC under this?

Martin, are we any closer to getting blk_() calls to kick off XCOPY
bios?

OCFS2 friends, is it a managable amount of work to implement an
ocfs2_splice_direct() that only modifies a region of the destination
file?

Finally, there's a slot in the plumbers schedule next week to talk
about this stuff. Come say hi if you're interested.

-z

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/