diff options
author | Stephen Warren <swarren@nvidia.com> | 2014-07-25 23:30:48 (GMT) |
---|---|---|
committer | Tom Rini <trini@ti.com> | 2014-08-09 15:17:03 (GMT) |
commit | f59be6e850b3856a4595b387c2b6c3607deb340a (patch) | |
tree | eef02626b50378b50926f9c780ff87b52e027a3f /disk/part_efi.c | |
parent | 194c1ed4006062235f8c2ebdaaf3866eccd278b7 (diff) | |
download | u-boot-f59be6e850b3856a4595b387c2b6c3607deb340a.tar.xz |
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>
Diffstat (limited to 'disk/part_efi.c')
0 files changed, 0 insertions, 0 deletions