Splice support for net.TCPConn.ReadFrom

[Andrei Tudor Călin]

Hello.

This is my first contribution to Go, so I hope I am following the proper process.

I am writing with regard to https://github.com/golang/go/issues/10948

I have implemented a proof of concept for this, loosely based on the patch posted in the

aforementioned issue. A diff is available here:

https://github.com/golang/go/compare/master...acln0:net-splice?diff=unified&name=net-splice

As it stands now, the quality of the patch is probably not very good, which is why I hesitated

to send a CL directly. The commit message explains what I did and the decisions I made.

I tried to follow the sendfile implementation in terms of file layout and general logic.

I don't have a very strong understanding of Go internals, in particular the network poller, so I

might have done something fundamentally wrong. However, the implementation seems to

pass tests, and the benchmarks (also included in the commit message) look fairly promising.

Sadly, I do not have a fast machine with a powerful network card, or proxies with a big workload

to test the actual effectiveness of the patch on. If the implementation is indeed correct, I expect

it to reduce CPU usage and increase throughput of TCP proxies or other servers with similar patterns.

Please advise on the next course of action, if you deem this to be an avenue worth pursuing.

Thank you.

Andrei

[Ian Lance Taylor]

Thanks. The goal of that issue, as @rsc mentions near the end, is to
figure out whether there is a way to use the splice system call
without introducing any new API. Your change adds a new Splice
function that is only available on GNU/Linux. That's not what we
ideally want. As much as possible, we want the net package to be OS
independent--to work exactly the same way on every OS. Of course that
is not really possible, but that's what we are trying for. Adding a
new function that only really works on GNU/Linux won't meet that goal.

Ian

[Andrei Tudor Călin]

My change doesn't introduce any new API, unless the internal/poll package counts.

Users of the net package should benefit from the change transparently, since the

entry point is (*net.TCPConn).ReadFrom, which is called when upper layers do

something like io.Copy(downstream, upstream) in a proxy.

[Ian Lance Taylor]

On Tue, Apr 17, 2018 at 7:24 AM, Andrei Tudor Călin <ma...@acln.ro> wrote:
>
> My change doesn't introduce any new API, unless the internal/poll package
> counts.
>
> Users of the net package should benefit from the change transparently, since
> the
> entry point is (*net.TCPConn).ReadFrom, which is called when upper layers do
> something like io.Copy(downstream, upstream) in a proxy.

Sorry, perhaps I am reading the patch wrong, but I thought I saw `func
Splice`, which would be new API.

Please don't hesitate to upload the patch to Gerrit even if it's not
ready. It would be a lot easier to review there. Thanks.

Ian

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Andrei Tudor Călin]

Understood. I'll clean it up to the best of my knowledge and upload it to Gerrit

soon. Thank you.

Andrei