• Thierry Reding's avatar
    net: More BOOTP retry timeout improvements · 92ac8acc
    Thierry Reding authored
    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 f59be6e8
    
     ("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: default avatarStephen Warren <swarren@nvidia.com>
    Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
    92ac8acc