Eliezer Croitoru <eliezer / ngtech.co.il> wrote:
> I am writing a tiny tcp proxy and I want to peek the connection and
> then if certain conditions are met maybe splice the two FDs to
> communicate one with the other leaving the kernel handle all the
> other levels of the FD.
> 
> The benefits that I expect are:
> - less userspace data copying
> - faster data transfer

Likely, yes.  But it's not a huge win either, due to syscall overhead.
Depends on the throughput involved.

One good side-effect with GC languages like Ruby is lower GC overhead.

> - less complexity handling the buffers in the userspace

I'm not certain about that.  It depends :)

> I do not know if linux Splice is the right choice for the task but I
> am almost sure it is.
>
> If someone have any recommendations I would be happy to read them.

Definitely keep up-to-date with the Linux kernel.  There were some
important performance/bug fixes in there from as recently as 2013; so
some older distros may be much slower or buggier; especially TCP
which does true zero-copy (Unix domain sockets do not, currently).

Non-blocking behavior was a bit confusing; but makes sense in the end.
You can resize pipes in newer kernel versions, which can improve
throughput.

haproxy might be a good example if you read C, as it's a TCP proxy.

I wrote dtas-player[1] in Ruby to (optionally) use splice+tee, but
mainly for fun and not performance.

Note: I'm the io_splice gem maintainer, too.

[1] git clone git://80x24.org/dtas  - lib/dtas/buffer/splice.c