Messages in this thread | | | Date | Fri, 31 Mar 2006 14:23:39 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] splice support #2 |
| |
On Fri, Mar 31 2006, Ingo Molnar wrote: > > * Linus Torvalds <torvalds@osdl.org> wrote: > > > - The pipe is the buffer #2: it's what allows you to do _other_ things > > with splice that are simply impossible to do with sendfile. Notably, > > splice allows very naturally the "readv/writev" scatter-gather > > behaviour of _mixing_ streams. If you're a web-server, with splice you > > can do > > > > write(pipefd, header, header_len); > > splice(file, pipefd, file_len); > > splice(pipefd, socket, total_len); > > > > (this is all conceptual pseudo-code, of course), and this very > > naturally has none of the issues that sendfile() has with plugging etc. > > There's never any "send header separately and do extra work to make > > sure it is in the same packet as the start of the data". > > with pipe-based buffering this approach has still the very same problems > that sendfile() has with packet boundaries, because it's not enough to > have "large enough" buffering (like a pipe has), the pipe also has to be > drained, and the networking layer has to know the precise boundary of > data. > > the right solution to the packet boundary problem is to pass in a proper > "does userspace expect more data right now" flag, or to let userspace > 'flush' the socket independently - which is independent of the > pipe-in-slice issue. This solution already exists: the MSG_MORE flag.
We can add a SPLICE_F_MORE flag for this, right now splice doesn't set the MSG_MORE flag for the end of the pipe.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |