net: BOOTP retry timeout improvements
authorStephen Warren <swarren@nvidia.com>
Fri, 25 Jul 2014 23:30:48 +0000 (17:30 -0600)
committerTom Rini <trini@ti.com>
Sat, 9 Aug 2014 15:17:03 +0000 (11:17 -0400)
commitf59be6e850b3856a4595b387c2b6c3607deb340a
treeeef02626b50378b50926f9c780ff87b52e027a3f
parent194c1ed4006062235f8c2ebdaaf3866eccd278b7
net: BOOTP retry timeout improvements

Currently, the BOOTP code sends out its initial request as soon as the
Ethernet driver indicates "link up". If this packet is lost or not
replied to for some reason, the code waits for a 1s timeout before
retrying. For some reason, such early packets are often lost on my
system, so this causes an annoying delay.

To optimize this, modify the BOOTP code to have very short timeouts for
the first packet transmitted, but gradually increase the timeout each
time a timeout occurs. This way, if the first packet is lost, the second
packet is transmitted quite quickly and hence the overall delay is low.
However, if there's still no response, we don't keep spewing out packets
at an insane speed.

It's arguably more correct to try and find out why the first packet is
lost. However, it seems to disappear inside my Ethenet chip; the TX chip
indicates no error during TX (not that it has much in the way of
reporting...), yet wireshark on the RX side doesn't see any packet.
FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is
reported too early or based on the wrong condition in HW, and we should
add some fixed extra delay into the driver. However, this would slow down
every link up event even if it ends up not being needed in some cases.
Having BOOTP retry quickly applies the fix/WAR to every possible
Ethernet device, and is quite simple to implement, so seems a better
solution.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
net/bootp.c
net/bootp.h
net/net.c