* getting rid of ->splice_write?
@ 2014-09-22 17:30 Christoph Hellwig
2014-11-05 18:49 ` Al Viro
0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2014-09-22 17:30 UTC (permalink / raw)
To: Al Viro; +Cc: Miklos Szeredi, linux-fsdevel, netdev
Currently only /dev/null, fusedev and the socket code have a
splice_write implementation that isn't iter_file_splice_write, and
it seems like these three could easily be switched over if they
implemented a ->write_iter.
Similarly it seems to be like we could kill ->splice_read by
implementing an equivalent iteration over ->read_iter.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: getting rid of ->splice_write?
2014-09-22 17:30 getting rid of ->splice_write? Christoph Hellwig
@ 2014-11-05 18:49 ` Al Viro
2014-11-06 7:55 ` Christoph Hellwig
0 siblings, 1 reply; 3+ messages in thread
From: Al Viro @ 2014-11-05 18:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Miklos Szeredi, linux-fsdevel, netdev
On Mon, Sep 22, 2014 at 10:30:53AM -0700, Christoph Hellwig wrote:
> Currently only /dev/null, fusedev and the socket code have a
> splice_write implementation that isn't iter_file_splice_write, and
> it seems like these three could easily be switched over if they
> implemented a ->write_iter.
Not really. A minor nitpick is that you've missed port_fops_splice_write(),
but the real bitch isn't that and not even the sockets (see the fun with
iov_iter sendmsg/recvmsg work getting resurrected). It's that NULL
->splice_write() means default_file_splice_write. IOW, you'd need either
->write_iter() for _everything_ (with support of bvec-backed ones included,
since that's what iter_file_splice_write() will feed to ->write_iter()),
or you need to have do_splice_from() check if ->write_iter is NULL and
go for default_file_splice_write() instead of iter_file_splice_write().
The latter might be doable, but the former is really over the top - for
that we'd need to touch every driver instance of ->write() out there.
You want to do that, it's your funeral...
> Similarly it seems to be like we could kill ->splice_read by
> implementing an equivalent iteration over ->read_iter.
Hard to do. I agree that we want to, but it'll take quite a bit of work
on iov_iter primitives, I'm afraid. At the very least, we want a variant
of iov_iter that could steal pages. Don't forget that a large part of
the rationale behind splice_read was the ability to play zero-copy games.
I'm not sure if it will happen this cycle; there's more than enough fun
on the net/* side. _If_ that ends up done faster than I expect it to be,
->splice_read() is the obvious next target.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: getting rid of ->splice_write?
2014-11-05 18:49 ` Al Viro
@ 2014-11-06 7:55 ` Christoph Hellwig
0 siblings, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2014-11-06 7:55 UTC (permalink / raw)
To: Al Viro; +Cc: Miklos Szeredi, linux-fsdevel, netdev
On Wed, Nov 05, 2014 at 06:49:45PM +0000, Al Viro wrote:
> Not really. A minor nitpick is that you've missed port_fops_splice_write(),
> but the real bitch isn't that and not even the sockets (see the fun with
> iov_iter sendmsg/recvmsg work getting resurrected). It's that NULL
> ->splice_write() means default_file_splice_write. IOW, you'd need either
> ->write_iter() for _everything_ (with support of bvec-backed ones included,
> since that's what iter_file_splice_write() will feed to ->write_iter()),
> or you need to have do_splice_from() check if ->write_iter is NULL and
> go for default_file_splice_write() instead of iter_file_splice_write().
>
> The latter might be doable, but the former is really over the top - for
> that we'd need to touch every driver instance of ->write() out there.
> You want to do that, it's your funeral...
The latter is what I thought off. And yes, the socket work looks good,
especially if we can get rid of ->sendpage as well. That'll require
passing new flags somewhere, the ones in the iocb added for
preadv2/pwritev2 might be usable.
> > Similarly it seems to be like we could kill ->splice_read by
> > implementing an equivalent iteration over ->read_iter.
>
> Hard to do. I agree that we want to, but it'll take quite a bit of work
> on iov_iter primitives, I'm afraid. At the very least, we want a variant
> of iov_iter that could steal pages. Don't forget that a large part of
> the rationale behind splice_read was the ability to play zero-copy games.
>
> I'm not sure if it will happen this cycle; there's more than enough fun
> on the net/* side. _If_ that ends up done faster than I expect it to be,
> ->splice_read() is the obvious next target.
And zero copy games would become a lot less nasty if they could go
straight through ->read_iter instead of the current abuses of splice
infrastructure.
Same for sendfile, btw.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-11-06 7:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-22 17:30 getting rid of ->splice_write? Christoph Hellwig
2014-11-05 18:49 ` Al Viro
2014-11-06 7:55 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).