On 03/15/2015 02:06 PM, Simon Kelley wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/03/15 00:15, Rick Jones wrote:
Does dnsmasq make any setsockopt(SO_SNDBUF) settings? Perhaps the
SO_SNDBUF has filled thanks to Linux's intra-stack flow-control and
an attempt to (non blocking?) send has triggered the EAGAIN?
Just guessing,
No, it doesn't change the buffer size. I think your guess may be a
good one.
I wonder some adaptive buffer-size expansion could be created?
Presumably, these are transient conditions right? I suppose there are a
few choices - one would be to queue the request internally and send it
again "later." Another would be to simply drop the request outright
(non-Linux stacks likely would have done so anyway and not necessarily
told the caller).
The third would be to tweak the SO_[SND|RCV]BUF explicitly. Under Linux
for that to "take" the administrator will have to have tweaked
net.core.[rw]mem_max. Otherwise Linux will silently cap any request
above that value.
As for how much buffer, I suppose for the SO_SNDBUF decision it would be
how much delay is one willing to add. Then figure how many sends could
be drained by the NIC in that length of time. If the Linux version is
new enough, it may already have fq_codel employed as the default qdisc
and there may already be a fair bit of buffering below the socket buffer.
If there are UDP receive errors being recorded (ie because dnsmasq
wasn't keeping-up with the incoming requests) then the computation would
be just how long one might reasonably expect a dnsmasq process to remain
blocked by something else and compute from there.
Lots of choices and "it depends" :)
rick
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
