[golang-dev] How to use syscall.Splice call instead of io.Copy during copy data from http Request connection for forwarding the request directly from kernel space

[subrata das]

Hi,

I will try to check the performance of proxy using syscal.Splice system
call to copy data of http Request to destination Server(So that proxy
quickly forward some requests directly to server). Instead of copying is
done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?

Because in func Splice(rfd int, roff *int64, wfd int, woff *int64, len int,
flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do we
retrieve fd value and the offset value ?

Thanks,
Subrata

[Brad Fitzpatrick]

You'll need to either modify the Go standard library (net, syscall, maybe
http), or you'll need to to avoid the standard library and use lots of
syscall. But even then you won't have access to the runtime's poller, so it
might be difficult. Your best bet for a prototype is just to modify the Go
standard library as an experiment.

Post by subrata das
Hi,
I will try to check the performance of proxy using syscal.Splice system
call to copy data of http Request to destination Server(So that proxy
quickly forward some requests directly to server). Instead of copying is
done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64, len
int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do we
retrieve fd value and the offset value ?
Thanks,
Subrata
--
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
For more options, visit https://groups.google.com/d/optout.

[James Bardin]

There was a proof of concept patch in issue #10948 (don't know if it still
applies cleanly)
https://github.com/golang/go/compare/master...philhofer:net-splice

Post by Brad Fitzpatrick
You'll need to either modify the Go standard library (net, syscall, maybe
http), or you'll need to to avoid the standard library and use lots of
syscall. But even then you won't have access to the runtime's poller, so it
might be difficult. Your best bet for a prototype is just to modify the Go
standard library as an experiment.

Post by subrata das
Hi,
I will try to check the performance of proxy using syscal.Splice system
call to copy data of http Request to destination Server(So that proxy
quickly forward some requests directly to server). Instead of copying is
done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64, len
int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do we
retrieve fd value and the offset value ?
Thanks,
Subrata
--
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
For more options, visit https://groups.google.com/d/optout.

[Philip Hofer]

This post might be inappropriate. Click to display it.

[Brad Fitzpatrick]

Yes, it's been proposed and debated. Exposing the underlying file
descriptor is a double-edged sword: it solves a lot of people's problems,
but it's also a maintainability nightmare, because now you never know what
people are doing with it, and what you might break if you modify the
then-very-constrained implementation. Or worse: you start to get mysterious
bug reports because assumptions the net package made no longer hold true
once people are messing with the fd behind its back.

Post by Philip Hofer
I'm happy to update that patch if it doesn't apply cleanly any more. I
hacked it together as a POC about a year ago and decided it was probably
too nasty to live in the stdlib.
I would, however, love to maintain it as a *separate* library, but I'd
need `net.Conn` to expose the file descriptor it is using, which it doesn't
do. (Has that ever been discussed? It seems like it would help eliminate
some hacks in /x/net too...)

Post by James Bardin
There was a proof of concept patch in issue #10948 (don't know if it
still applies cleanly)
https://github.com/golang/go/compare/master...philhofer:net-splice

Post by Brad Fitzpatrick
You'll need to either modify the Go standard library (net, syscall,
maybe http), or you'll need to to avoid the standard library and use lots
of syscall. But even then you won't have access to the runtime's poller, so
it might be difficult. Your best bet for a prototype is just to modify the
Go standard library as an experiment.

Post by subrata das
Hi,
I will try to check the performance of proxy using syscal.Splice system
call to copy data of http Request to destination Server(So that proxy
quickly forward some requests directly to server). Instead of copying is
done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64, len
int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do we
retrieve fd value and the offset value ?
Thanks,
Subrata
--
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
For more options, visit https://groups.google.com/d/optout.

--

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
For more options, visit https://groups.google.com/d/optout.

[Philip Hofer]

Yeah, I figured this had been discussed before.

FWIW, at literally *every* go shop I've ever worked at, we've had to crack
open the net library (or do some pointer-casting) for precisely this
reason; send/recvmsg, setsockopt, and ioctl are all pretty popular.

The alternative here is to expose enough of the netpoller that one could
write an alternative net library with all the linux/posix baggage in it.
Right now it's not possible without shipping a patched runtime, too.

Post by Brad Fitzpatrick
Yes, it's been proposed and debated. Exposing the underlying file
descriptor is a double-edged sword: it solves a lot of people's problems,
but it's also a maintainability nightmare, because now you never know what
people are doing with it, and what you might break if you modify the
then-very-constrained implementation. Or worse: you start to get mysterious
bug reports because assumptions the net package made no longer hold true
once people are messing with the fd behind its back.

Post by Philip Hofer
I'm happy to update that patch if it doesn't apply cleanly any more. I
hacked it together as a POC about a year ago and decided it was probably
too nasty to live in the stdlib.
I would, however, love to maintain it as a *separate* library, but I'd
need `net.Conn` to expose the file descriptor it is using, which it doesn't
do. (Has that ever been discussed? It seems like it would help eliminate
some hacks in /x/net too...)

Post by James Bardin
There was a proof of concept patch in issue #10948 (don't know if it
still applies cleanly)
https://github.com/golang/go/compare/master...philhofer:net-splice

Post by Brad Fitzpatrick
You'll need to either modify the Go standard library (net, syscall,
maybe http), or you'll need to to avoid the standard library and use lots
of syscall. But even then you won't have access to the runtime's poller, so
it might be difficult. Your best bet for a prototype is just to modify the
Go standard library as an experiment.

Post by subrata das
Hi,
I will try to check the performance of proxy using syscal.Splice
system call to copy data of http Request to destination Server(So that
proxy quickly forward some requests directly to server). Instead of copying
is done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64, len
int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do we
retrieve fd value and the offset value ?
Thanks,
Subrata
--
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
For more options, visit https://groups.google.com/d/optout.

--

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
For more options, visit https://groups.google.com/d/optout.

[Brad Fitzpatrick]

Exposing the runtime poller seems like the ideal fix. It's a little weird
that net is special at all.

Post by Philip Hofer
Yeah, I figured this had been discussed before.
FWIW, at literally *every* go shop I've ever worked at, we've had to crack
open the net library (or do some pointer-casting) for precisely this
reason; send/recvmsg, setsockopt, and ioctl are all pretty popular.
The alternative here is to expose enough of the netpoller that one could
write an alternative net library with all the linux/posix baggage in it.
Right now it's not possible without shipping a patched runtime, too.

Post by Brad Fitzpatrick
Yes, it's been proposed and debated. Exposing the underlying file
descriptor is a double-edged sword: it solves a lot of people's problems,
but it's also a maintainability nightmare, because now you never know what
people are doing with it, and what you might break if you modify the
then-very-constrained implementation. Or worse: you start to get mysterious
bug reports because assumptions the net package made no longer hold true
once people are messing with the fd behind its back.

Post by Philip Hofer
I'm happy to update that patch if it doesn't apply cleanly any more. I
hacked it together as a POC about a year ago and decided it was probably
too nasty to live in the stdlib.
I would, however, love to maintain it as a *separate* library, but I'd
need `net.Conn` to expose the file descriptor it is using, which it doesn't
do. (Has that ever been discussed? It seems like it would help eliminate
some hacks in /x/net too...)

Post by James Bardin
There was a proof of concept patch in issue #10948 (don't know if it
still applies cleanly)
https://github.com/golang/go/compare/master...philhofer:net-splice

Post by Brad Fitzpatrick
You'll need to either modify the Go standard library (net, syscall,
maybe http), or you'll need to to avoid the standard library and use lots
of syscall. But even then you won't have access to the runtime's poller, so
it might be difficult. Your best bet for a prototype is just to modify the
Go standard library as an experiment.

Post by subrata das
Hi,
I will try to check the performance of proxy using syscal.Splice
system call to copy data of http Request to destination Server(So that
proxy quickly forward some requests directly to server). Instead of copying
is done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64,
len int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do
we retrieve fd value and the offset value ?
Thanks,
Subrata
--
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,
For more options, visit https://groups.google.com/d/optout.

--

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
For more options, visit https://groups.google.com/d/optout.

[Philip Hofer]

Is there (or has there been) a design proposal? I'd like to see this happen.

Exposing the runtime poller seems like the ideal fix. It's a little weird that net is special at all.

Post by Philip Hofer
Yeah, I figured this had been discussed before.
FWIW, at literally *every* go shop I've ever worked at, we've had to crack open the net library (or do some pointer-casting) for precisely this reason; send/recvmsg, setsockopt, and ioctl are all pretty popular.
The alternative here is to expose enough of the netpoller that one could write an alternative net library with all the linux/posix baggage in it. Right now it's not possible without shipping a patched runtime, too.

Yes, it's been proposed and debated. Exposing the underlying file descriptor is a double-edged sword: it solves a lot of people's problems, but it's also a maintainability nightmare, because now you never know what people are doing with it, and what you might break if you modify the then-very-constrained implementation. Or worse: you start to get mysterious bug reports because assumptions the net package made no longer hold true once people are messing with the fd behind its back.

I'm happy to update that patch if it doesn't apply cleanly any more. I hacked it together as a POC about a year ago and decided it was probably too nasty to live in the stdlib.
I would, however, love to maintain it as a *separate* library, but I'd need `net.Conn` to expose the file descriptor it is using, which it doesn't do. (Has that ever been discussed? It seems like it would help eliminate some hacks in /x/net too...)

There was a proof of concept patch in issue #10948 (don't know if it still applies cleanly)
https://github.com/golang/go/compare/master...philhofer:net-splice

You'll need to either modify the Go standard library (net, syscall, maybe http), or you'll need to to avoid the standard library and use lots of syscall. But even then you won't have access to the runtime's poller, so it might be difficult. Your best bet for a prototype is just to modify the Go standard library as an experiment.

Hi,
I will try to check the performance of proxy using syscal.Splice system call to copy data of http Request to destination Server(So that proxy quickly forward some requests directly to server). Instead of copying is done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64, len int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do we retrieve fd value and the offset value ?
Thanks,
Subrata
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
For more options, visit https://groups.google.com/d/optout.

[Brad Fitzpatrick]

None that I recall.

Post by Philip Hofer
Is there (or has there been) a design proposal? I'd like to see this happen.
Exposing the runtime poller seems like the ideal fix. It's a little weird
that net is special at all.

Post by Philip Hofer
Yeah, I figured this had been discussed before.
FWIW, at literally *every* go shop I've ever worked at, we've had to
crack open the net library (or do some pointer-casting) for precisely this
reason; send/recvmsg, setsockopt, and ioctl are all pretty popular.
The alternative here is to expose enough of the netpoller that one could
write an alternative net library with all the linux/posix baggage in it.
Right now it's not possible without shipping a patched runtime, too.

Post by Brad Fitzpatrick
Yes, it's been proposed and debated. Exposing the underlying file
descriptor is a double-edged sword: it solves a lot of people's problems,
but it's also a maintainability nightmare, because now you never know what
people are doing with it, and what you might break if you modify the
then-very-constrained implementation. Or worse: you start to get mysterious
bug reports because assumptions the net package made no longer hold true
once people are messing with the fd behind its back.

Post by Philip Hofer
I'm happy to update that patch if it doesn't apply cleanly any more. I
hacked it together as a POC about a year ago and decided it was probably
too nasty to live in the stdlib.
I would, however, love to maintain it as a *separate* library, but I'd
need `net.Conn` to expose the file descriptor it is using, which it doesn't
do. (Has that ever been discussed? It seems like it would help eliminate
some hacks in /x/net too...)

Post by James Bardin
There was a proof of concept patch in issue #10948 (don't know if it
still applies cleanly)
https://github.com/golang/go/compare/master...philhofer:net-splice

Post by Brad Fitzpatrick
You'll need to either modify the Go standard library (net, syscall,
maybe http), or you'll need to to avoid the standard library and use lots
of syscall. But even then you won't have access to the runtime's poller, so
it might be difficult. Your best bet for a prototype is just to modify the
Go standard library as an experiment.

Post by subrata das
Hi,
I will try to check the performance of proxy using syscal.Splice
system call to copy data of http Request to destination Server(So that
proxy quickly forward some requests directly to server). Instead of copying
is done in User Space,
I want some requests need to copy directly from the Kernel space itself.
Can you help me how do we proceed to solve this problem ?
Because in func Splice(rfd int, roff *int64, wfd int, woff *int64,
len int, flags int) (n int64, err error) , read and write fds are required
So, I couldn't understand from the net.Conn or http.Request, how do
we retrieve fd value and the offset value ?
Thanks,
Subrata
--
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,
For more options, visit https://groups.google.com/d/optout.

--

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
For more options, visit https://groups.google.com/d/optout.