Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net: zoneToIndex will not cache the RIB and is called on each IPv6-linklocal datagram read #15237
Please answer these questions before submitting your issue. Thanks!
This is a performance issue rather than an error. When ReadFromUDP returns with an IPv6
To see the problem the following code can be run with strace -f on linux:
changed the title
zoneToIndex will not cache the RIB and is called on every ReadFromUDP
Apr 11, 2016
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.
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
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