Bug #42446 for dhcp-public: [PATCH] Compile in delayed-ack feature by default but disable it at runtime

Dear sir/madam, A couple of years ago I enquired about whether any users had had any poor experiences with using delayed-ack alongside failover [i]. The answers that were forthcoming where that delayed-ack seems to work fine which matches my own positive experiences. Perhaps ISC knows different? This lead to me raising a proposal for the delayed-ack feature to be compiled in by default [ii]. The following is a refresh of that proposal. Please could you review and if suitable pull the following: https://github.com/terryburton/isc-dhcp/commit/b712dc011e1ce67a3aa78db7f9a52733f9cf1a29 As a patch (also attached): https://github.com/terryburton/isc-dhcp/commit/b712dc011e1ce67a3aa78db7f9a52733f9cf1a29.diff Summary below... [i] https://lists.isc.org/pipermail/dhcp-users/2014-November/018386.html [ii] https://lists.isc.org/pipermail/dhcp-hackers/2014-December/002102.html Many thanks, Terry ---- ISC recommends the use of delayed-ack [1] yet this feature is still described as experimental and is omitted from the build by default. Myself and others [2] have had success with this feature in high-throughput failover configurations and would like to see --enable-delayed-ack default to yes. This patch enables delayed-ack in the default build. To mitigate any potentially harmful effects in untested configurations the default "delayed-ack" runtime configuration parameter has been amended to default to 0, rather than 28. The condition that decides between delayed- vs. immediate-ack has been amended so that it will immediately ack if the delayed-ack parameter has not been updated from the default of 0. This means that users are not accidentally exposed to the "experimental" code path, only if they add a delayed-ack parameter other than 0 to dhcpd.conf. Pros: * Delayed-ack support will be available without recompiling and will therefore find its way into distributions. * This will increase the amount of testing that this feature receives due to increased exposure - hopefully getting it out of experimental status sooner. * ISC DHCP then benefits from hugely increased performance without having to declare caveats. Cons: * Minor upgrade risk for users already compiling in delayed-ack support without specifying an explicit "delayed-ack" parameter in dhcpd.conf. Those who rely on the current default (28) will find it changed (0) thereby disabling the feature at runtime. Setting delayed-ack to 28 in dhcpd.conf will re-enable the previous behaviour. Perhaps a release note is sufficient to cover this? [1] https://deepthought.isc.org/article/AA-00373/0/Synchronous-Disk-Writes-and-DHCP-Performance-Limitations.html [2] https://lists.isc.org/pipermail/dhcp-users/2014-November/018387.html

---