net: More BOOTP retry timeout improvements

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>
Signed-off-by: Thierry Reding <treding@nvidia.com>

1 files changed, 18 insertions, 0 deletions

diff --git a/README b/README
index 1d71359..d1b4eed 100644
--- a/README
+++ b/README
@@ -2036,6 +2036,24 @@ CBFS (Coreboot Filesystem) support
 		4th and following
 		BOOTP requests:		delay 0 ... 8 sec
 
+		CONFIG_BOOTP_ID_CACHE_SIZE
+
+		BOOTP packets are uniquely identified using a 32-bit ID. The
+		server will copy the ID from client requests to responses and
+		U-Boot will use this to determine if it is the destination of
+		an incoming response. Some servers will check that addresses
+		aren't in use before handing them out (usually using an ARP
+		ping) and therefore take up to a few hundred milliseconds to
+		respond. Network congestion may also influence the time it
+		takes for a response to make it back to the client. If that
+		time is too long, U-Boot will retransmit requests. In order
+		to allow earlier responses to still be accepted after these
+		retransmissions, U-Boot's BOOTP client keeps a small cache of
+		IDs. The CONFIG_BOOTP_ID_CACHE_SIZE controls the size of this
+		cache. The default is to keep IDs for up to four outstanding
+		requests. Increasing this will allow U-Boot to accept offers
+		from a BOOTP client in networks with unusually high latency.
+
 - DHCP Advanced Options:
 		You can fine tune the DHCP functionality by defining
 		CONFIG_BOOTP_* symbols: