-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Havard,
On 05/10/15 14:43, Havard Eidnes via Unbound-users wrote:
> Hi,
>
> it looks like I'll have to answer my own question, which is a
> little disappointing:
>
>> I'm running unbound 1.5.4 on NetBSD/amd64 7.0, and I notice that
>> despite me having configured
>>
>> server: num-threads: 12 so-reuseport: yes
>>
>> only one of the threads is handling all the queries, according
>> to the output from "unbound-control stats". "Not what I
>> wanted."
>
> It turns out that using the "so-reuseport" setting to distribute
> the load over the threads is a fairly recent Linuxism, and relying
> on it causing the kernel to distribute the load over the different
> sockets is not portable.
Yes, I did not realise this. If you disable reuseport on BSD I think
it will start to work.
>
> The first answer in
>
> http://stackoverflow.com/questions/14388706/socket-options-so-reuseadd
r-and-so-reuseport-how-do-they-differ-do-they-mean-t
>
> says it quite clearly:
>
> Linux 3.9 added the option SO_REUSEPORT to Linux as well. [...]
> Additionally the kernel performs some "special magic" for
> SO_REUSEPORT sockets that isn't found in any other operating system
> so far: For UDP sockets, it tries to distribute datagrams evenly,
> for TCP listening sockets, it tries to distribute incoming connect
> requests (those accepted by calling accept()) evenly across all the
> sockets that share the same address and port combination. [...]
>
> I'll try to turn off the so-reuseport option later today, and see
> if that improves the situation.
The option provides nice benefits on Linux; somehow having one file
descriptor per thread/process that is tied to the same socket allows
for much faster operation in the network stack.
Best regards, Wouter
>
> Regards,
>
> - Håvard
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWEnK/AAoJEJ9vHC1+BF+N1v8P+gKLb2H6TDIQiV9ZFvEfg18Y
JQN6jdL1MaDQFQO07SRt3xTKP+GRVy8M3FrSIFC0GeFIR2IYku9FJz7cHFchU3Dp
TimQd6tP/D6qOoOT3W6zoGAFy+RREoc3ZJK66nLMOY5U6PWlgekJsHwgH+LN1whO
2WWSg7om7Fe0xpYdhKaTlBpliWHDXO/J/8jBd+v1+SCqWpg+EsH8NUQkzNEoHE8q
EGs6TjKv/UgnumzapPlKgA2PxGUQArdwCrY4V7/5AdLUa+9qxLjAvu+X17Sj7iHd
grXbygi/h4kXjZyPx9KbzTCtG1NNH1n/cFcfAoGi4n+UBFAfrSr3dF8r/n9CIXCw
M/OmEZ592sKMihtVk5qWi2uXMJD6OPZoCLC+7SEhSfkPTaI4P7phlczBEmt9i9Ro
fCOezRVRg75GU4t1A5vtVLV+SHlFV6wfsaxbLgOSi8OpTmlOs6HvfFlr7wnQb/Jd
OUu30ltwbV3kLVJQngSAtOAOByt6dviCJwcjk5S/LEqOOfTJ1iT809OMI4y3E0aY
t1N+tBXi3MtvQaeid9Drf9COVWIrmj6qFwZuLH+wdPbXKuRpeSdYOi+0HgYMBUBP
6N9DDF3CykVNBJeJMyEsmuIczRRsUZxIGv0Ls0wCLeeBpxmCF0wpicKAu8Z2n8xa
V4hZ0GAkNMOHNY031vRR
=EoJr
-END PGP SIGNATURE-
