public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] net: BOOTP retry timeout improvements
Date: Fri, 15 Aug 2014 14:39:45 +0200	[thread overview]
Message-ID: <20140815123944.GA2134@ulmo> (raw)
In-Reply-To: <1406331048-27700-1-git-send-email-swarren@wwwdotorg.org>

On Fri, Jul 25, 2014 at 05:30:48PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@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@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>

  parent reply	other threads:[~2014-08-15 12:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 23:30 [U-Boot] [PATCH] net: BOOTP retry timeout improvements Stephen Warren
2014-08-06 15:58 ` Stephen Warren
2014-08-06 18:10   ` Tom Rini
2014-08-06 20:03 ` Joe Hershberger
2014-08-10 22:22 ` [U-Boot] " Tom Rini
2014-08-15 12:39 ` Thierry Reding [this message]
2014-08-15 12:49   ` [U-Boot] [PATCH] " Thierry Reding
2014-08-15 16:02     ` Stephen Warren
2014-08-15 21:39       ` Thierry Reding
2014-08-15 22:09         ` Thierry Reding
2014-08-18 16:04         ` Stephen Warren
2014-08-18 16:15           ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140815123944.GA2134@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox