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

[Thierry Reding]

On Fri, Jul 25, 2014 at 05:30:48PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren at nvidia.com>
> 
> 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 at nvidia.com>
> ---
>  net/bootp.c | 38 +++++++++++++++++++++++++++++++-------
>  net/bootp.h |  3 +--
>  net/net.c   |  4 ++--
>  3 files changed, 34 insertions(+), 11 deletions(-)

Sorry for jumping in a little late, but I only encountered this after
rebasing on latest origin/master today.

With this patch applied, it takes about 8 seconds until U-Boot manages
to get a DHCP address (it needs to broadcast 14 times) whereas with the
patch reverted I get a reply almost instantly (with only a single
broadcast).

I'm testing this on a Jetson TK1 (with local patches for PCIe and
ethernet support).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140815/f9fb13a8/attachment.pgp>