[LSF/MM TOPIC] reverse splice

[LSF/MM TOPIC] reverse splice

[Miklos Szeredi]

rsplice would serve a similar purpose as splice, but in the other
direction.  I.e. instead of operating on buffers filled with data, it
would operate on empty buffers to be filled with data.  rsplice is to
splice as read is to write.

data source -> splice -> data destination
data destination -> rsplice -> data source

One use case would be zero-copy read in fuse.   Zero-copy writes work
with plain splice: page cache pages or userspace buffers are passed
through to the userspace filesystem server as pipe buffers and they
can be directed wherever the filesystem wants.   The reverse doesn't
work.  There's code to attempt stealing pages and inserting into the
fuse page cache, but this is far from being as generic as the write
path.

What do people think?  Is this crazy?  Are there major roadblocks for
implementation?  Would this have any other use cases?

To me it looks like this is pretty symmetrical with normal splice, the
big difference being that uninitialized buffers would be passed
around.  Obviously must make sure those buffers are write only, i.e.
the previous contents are inaccessible.

Thanks,
Miklos

Re: [LSF/MM TOPIC] reverse splice

[Matthew Wilcox]

On Thu, Feb 21, 2019 at 01:56:11PM +0100, Miklos Szeredi wrote:
> rsplice would serve a similar purpose as splice, but in the other
> direction.  I.e. instead of operating on buffers filled with data, it
> would operate on empty buffers to be filled with data.  rsplice is to
> splice as read is to write.
> 
> data source -> splice -> data destination
> data destination -> rsplice -> data source
> 
> One use case would be zero-copy read in fuse.   Zero-copy writes work
> with plain splice: page cache pages or userspace buffers are passed
> through to the userspace filesystem server as pipe buffers and they
> can be directed wherever the filesystem wants.   The reverse doesn't
> work.  There's code to attempt stealing pages and inserting into the
> fuse page cache, but this is far from being as generic as the write
> path.
> 
> What do people think?  Is this crazy?  Are there major roadblocks for
> implementation?  Would this have any other use cases?

This was something I was interested in last year for a project at my
then-employer.  It's not something I'm interested in right now, but I
could imagine it becoming interesting to me again fairly rapidly.

It's one of those projects I have to think very hard about and I don't
have the spare cycles to do that today.  So I think it should be done,
but I should probably stay focused on my other projects right now.

Re: [LSF/MM TOPIC] reverse splice

[Matthew Wilcox]

... also, this really needs to be cc'd to linux-mm.

On Thu, Feb 21, 2019 at 01:56:11PM +0100, Miklos Szeredi wrote:
> rsplice would serve a similar purpose as splice, but in the other
> direction.  I.e. instead of operating on buffers filled with data, it
> would operate on empty buffers to be filled with data.  rsplice is to
> splice as read is to write.
> 
> data source -> splice -> data destination
> data destination -> rsplice -> data source
> 
> One use case would be zero-copy read in fuse.   Zero-copy writes work
> with plain splice: page cache pages or userspace buffers are passed
> through to the userspace filesystem server as pipe buffers and they
> can be directed wherever the filesystem wants.   The reverse doesn't
> work.  There's code to attempt stealing pages and inserting into the
> fuse page cache, but this is far from being as generic as the write
> path.
> 
> What do people think?  Is this crazy?  Are there major roadblocks for
> implementation?  Would this have any other use cases?
> 
> To me it looks like this is pretty symmetrical with normal splice, the
> big difference being that uninitialized buffers would be passed
> around.  Obviously must make sure those buffers are write only, i.e.
> the previous contents are inaccessible.
> 
> Thanks,
> Miklos