In general I like the change. Fixed number does not scale. I would move max_procs in dnsmasq right after tcp_pipes. It belongs to it and is directly related. I would add into comment  /* tcp_pipes size */, because the name does not make it obvious. Maybe even call it tcp_pipes_sz instead of max_procs. I would use unsigned int as a type, negative value does not make sense for it anyway.

I think whole TCP handling concept is unfortunate and slow. It allocates 64kB for each TCP socket I think, which is no issue on any today's hardware. But some old routers may have too little of memory. I may have mistaken this with avahi, it does it similar way. This is a minimal change to archieve non-crashing results. I would expect just 4kB buffer would be enough for almost anything, it should just reallocate the buffer if that is not enough. But that would require careful changes to not break anything else.

Even better it should handle TCP inside main process with non-blocking socket API, without extra forks spawned. But that has to wait.

I recommend using option edns0 inside /etc/resolv.conf on any clients where it can work, to avoid TCP queries if possible. TCP queries have worse failover implementation and are much slower than UDP queries.

Anyway, nice change in my opinion.

Cheers,
Petr

On 12. 10. 23 0:36, Damian Sawicki via Dnsmasq-discuss wrote:
Hello dnsmasq experts,

I'd like to propose a patch adding a flag to customise MAX_PROCS. I know this was already suggested in https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014907.html for other reasons and rejected back then. My motivation is that in some use cases in Kubernetes, MAX_PROCS is actually a bottleneck, so it would be great to have the possibility to customise this limit depending on the load.

Do you think that this patch is enough or would it be good to have insight into the utilisation? I've prepared another patch that introduces logs with the information on the number of child processes (behind a feature flag). Could you please advise?

Please kindly let me know what you think.

Kind regards,

Damian Sawicki

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Attachment: OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Reply via email to