[U-Boot] [PATCH] net: More BOOTP retry timeout improvements

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/18/2014 12:45 AM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> It's not unusual for DHCP servers to take a couple hundred milliseconds
> to respond to DHCP discover messages. One possible reason for the delay
> can be that the server checks (typically using an ARP request) that the
> IP it's about to hand out isn't in use yet. To make matters worse, some
> servers may also queue up requests and process them sequentially, which
> can cause excessively long delays if clients retry too fast.
>
> Commit f59be6e850b3 ("net: BOOTP retry timeout improvements") shortened
> the retry timeouts significantly, but the BOOTP/DHCP implementation in
> U-Boot doesn't handle that well because it will ignore incoming replies
> to earlier requests. In one particular setup this increases the time it
> takes to obtain a DHCP lease from 630 ms to 8313 ms.
>
> This commit attempts to fix this in two ways. First it increases the
> initial retry timeout from 10 ms to 250 ms to give DHCP servers some
> more time to respond. At the same time a cache of outstanding DHCP
> request IDs is kept so that the implementation will know to continue
> transactions even after a retransmission of the DISCOVER message. The
> maximum retry timeout is also increased from 1 second to 2 seconds. An
> ID cache of size 4 will keep DHCP requests around for 8 seconds (once
> the maximum retry timeout has been reached) before dropping them. This
> should give servers plenty of time to respond. If it ever turns out
> that this isn't enough, the size of the cache can easily be increased.
>
> With this commit the DHCP lease on the above-mentioned setup still takes
> longer (1230 ms) than originally, but that's an acceptable compromise to
> improve DHCP lease acquisition time for a broader range of setups.
>
> To make it easier to benchmark DHCP in the future, this commit also adds
> the time it took to obtain a lease to the final "DHCP client bound to
> address x.x.x.x" message.

Tested-by: Stephen Warren <swarren@nvidia.com>

So long as it's considered safe to accept DHCP responses to older 
requests, this approach seems fine. Having seen this patch now (I hadn't 
when I responded to the other thread), I guess I don't have a strong an 
opinion re: reverting my original patch vs. taking this; net 
maintainers, feel free to decide:-)