I want splice() to work with two tcp sockets().I think to implement
this. Two questions:
1. Is any work in this direction?
2. Why this functionality does not implemented now? any difficulties?
I think API should consist of 2 main functions:
1. detach available buffers from fd1 (and save info in some struct)
2. attach buffers to fd2 (from this struct)
this functions should be called under some lock to guarantee
atomicity. if something happen, return buffers back to original file.
I mean, that, for example, skb_splice_bits should not splice into
pipe..... it should splice skb into list of kernel buffers independent
from the "type" of fd (socket, file, and so on...)
At now, I think that the most quick way to acheive my results, is to
create intermediate temporary pipe inside kernel and splice from
non-pipe fd to pipe, and than from pipe to second non-pipe fd.
Is this method appropriate, as you think ?
Марк Коренберг wrote:
> I want splice() to work with two tcp sockets().I think to implement
> this. Two questions:
This works already by introducing a pipe between the two:
while (0 < (len = splice(sock1, 0, pipe, 0, max_len, some_flags)))
splice(pipe, 0, sock2, 0, len, some_flags);
Just like with read(2) and write(2), but without copy to/from userspace.
> 1. Is any work in this direction?
> 2. Why this functionality does not implemented now? any difficulties?
>
> I think API should consist of 2 main functions:
> 1. detach available buffers from fd1 (and save info in some struct)
> 2. attach buffers to fd2 (from this struct)
> this functions should be called under some lock to guarantee
> atomicity. if something happen, return buffers back to original file.
What about full duplex?
> At now, I think that the most quick way to acheive my results, is to
> create intermediate temporary pipe inside kernel and splice from
> non-pipe fd to pipe, and than from pipe to second non-pipe fd.
Have a look at the "sendfile emulation" in fs/splice.c. Maybe you can
generalize that in some way or the other.
Enrik