-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net: zoneToIndex will not cache the RIB and is called on each IPv6-linklocal datagram read #15237
Comments
Do you have any numbers on performance? |
No, not yet. The UDP traffic I need to handle is too slow to be impacted by this. What I will try to make some kind of test-bench to compare ReadFromUDP and plain Read |
You perhaps might find github.com/mikioh/bulk helpful. It implements dumb cache for IPv6 addressing scope zone. Out of curiosity, what's your application? I wonder (nowadays) what type of application requires really fast (up to 1G bps/1.5M pps?) UDP over IPv6-linklocal transport, except peer-to-peer stuff on wireless/mobile ad-hoc network. |
Unlink BSD variants, some Linux distributions restrict IPv6-linklocal traffic for some reasons. You need to let them free before IPv6-linklocal benchmarking. |
My applications are two different RTP implementations. One is audio over RTP and the second is RTP-MIDI. Neither have high bandwidth requirements. The RTP-MIDI protocol is however quite sensitive to latency and jitter. The RTP audio is not as sensitive but the lower the latency the better. I have made some performance tests. The code is at http://play.golang.org/p/CTzoRQSt6l it can't be run on the playground of course. When running it in linux I get
and it's even worse on Windows, albeit on a slower machine:
|
Is there any specific reason why not to use IPv6 global addresses for your datagram-based real-time application? Just for benchmarking? I think the workaround would be to use IPv6 addresses that are greater than link-local scope. Also I made a simple patch. What happens when you give https://go-review.googlesource.com/#/c/21952/ a shot? |
I'm not really in control of the addresses if the hosts where the code will run. I worked around the problem in my code already using UDPConn.Read instead of UDPConn.ReadFromUDP I tried the patch and the performance looks good.
Looks OK in Windows too
|
CL https://golang.org/cl/21952 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
go version
)?go version go1.6 linux/amd64
go env
)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/magnus/Projects/go"
GORACE=""
GOROOT="/opt/go"
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
This is a performance issue rather than an error. When ReadFromUDP returns with an IPv6
address of the peer it will map the Zone field using zoneToString. This will call syscall.NetlinkRIB
to get the interfaces of the host. This information is not cached and syscall.NetlinkRIB will be called
for every received packet.
To see the problem the following code can be run with strace -f on linux:
The text was updated successfully, but these errors were encountered: