Does this patch fix the issue? It should be equivalent to adding a new process.
There is still an issue because UDP deliver_iob() does not fail when the packet is dropped due to an ARP cache miss. This means TFTP cannot determine whether a packet it sent was handed to the network device. I haven't audited other UDP user code but it is possible we could change UDP so that users know when packets are hitting the wire versus waiting for ARP. Stefan
From f5cd00b21b2aba412c8fc1b92bae7d3312eee8fa Mon Sep 17 00:00:00 2001 From: Stefan Hajnoczi <[email protected]> Date: Wed, 13 Jan 2010 17:57:41 +0000 Subject: [tftp] Remove unnecessary delay when opening a connection The retry timer is used to retransmit TFTP packets lost on the network, and to start a new connection. There is an unnecessary delay while waiting for name resolution because the timer period is fixed and cannot be shortened when name resolution completes. This patch keeps the timer period at zero while name resolution takes place so that no time is lost once before sending the first packet. Reported-by: Thomas Horsten <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> --- src/net/udp/tftp.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/net/udp/tftp.c b/src/net/udp/tftp.c index 1dc8d3b..70f3133 100644 --- a/src/net/udp/tftp.c +++ b/src/net/udp/tftp.c @@ -445,9 +445,16 @@ static int tftp_send_ack ( struct tftp_request *tftp ) { */ static int tftp_send_packet ( struct tftp_request *tftp ) { - /* Update retransmission timer */ + /* Update retransmission timer. While name resolution takes place the + * window is zero. Avoid unnecessary delay after name resolution + * completes by retrying immediately. + */ stop_timer ( &tftp->timer ); - start_timer ( &tftp->timer ); + if ( xfer_window ( &tftp->socket ) ) { + start_timer ( &tftp->timer ); + } else { + start_timer_nodelay ( &tftp->timer ); + } /* Send RRQ or ACK as appropriate */ if ( ! tftp->peer.st_family ) { -- 1.6.5
_______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
