Re: [PATCH] splice support #2

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxx> 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.

	Ingo
-
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/