2013-03-30 19:45:17

by Pavel Machek

[permalink] [raw]
Subject: Re: New copyfile system call - discuss before LSF?

Hi!

> > > If I'm guessing correctly, sendfile64()+flags would be annoying because it's
> > > missing an out_fd_offset. The host will want to offload the guest's copies by
> > > calling sendfile on block ranges of a guest disk image file that correspond to
> > > the mappings of the in and out files in the guest.
> > >
> > > You could make it work with some locking and out_fd seeking to set the
> > > write offset before calling sendfile64()+flags, but ugh.
> > >
> > > ssize_t sendfile(int out_fd, int in_fd, off_t in_offset, off_t
> > > out_offset, size_t count, int flags);
> > >
> > > That seems closer.
> >
> > psendfile() ?
> >
> > I fully agree that sounds reasonable... Just being an ass. :-)
>
> splice() already has offset for both fds and a flags arg:
>
> ssize_t splice(int fd_in, loff_t *off_in, int fd_out,
> loff_t *off_out, size_t len, unsigned int flags);
>
> The current downside is it requires one fd to be a pipe, so it's
> just not very easy to use from my perspective[1].
...
> [1] my splice() annoyances:
> * need to create/manage a pipe
> * copy size limited by pipe size
> * doesn't reduce userspace syscalls (just data copy overhead)
> * easy to misuse and starve with blocking sockets + big buffers
> * not many users, so bugs creep in (v3.7.8 was the first usable
> version of the 3.7 series for TCP sockets)

Could library be created to make it less annoying to use, and harder
to misuse?

splice man page does not mention pipe size limit...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


2013-03-31 21:23:59

by Eric Wong

[permalink] [raw]
Subject: Re: New copyfile system call - discuss before LSF?

Pavel Machek <[email protected]> wrote:
> Eric Wong wrote:
> > [1] my splice() annoyances:
> > * need to create/manage a pipe
> > * copy size limited by pipe size
> > * doesn't reduce userspace syscalls (just data copy overhead)
> > * easy to misuse and starve with blocking sockets + big buffers
> > * not many users, so bugs creep in (v3.7.8 was the first usable
> > version of the 3.7 series for TCP sockets)
>
> Could library be created to make it less annoying to use, and harder
> to misuse?

Maybe, but getting people to use the library would be the hard, too.
And a library would not reduce syscalls in the common case.

We already have current->splice_pipe for sendfile, so maybe splice can
be taught to transparently use that when neither FD is a pipe.

I also think a SPLICE_F_DONTWAIT flag might be necessary. It would be a
superset of SPLICE_F_NONBLOCK, but also act like MSG_DONTWAIT for the
non-pipe socket.

> splice man page does not mention pipe size limit...

It probably should. I think I discovered it by using it many years ago
and burned it into my mind.