[gPXE] [Etherboot-developers] [PATCH] [tftp] Kick off TFTP RRQ from a process to avoid losing first packet

[Thomas Horsten]

2010/1/14 Stefan Hajnoczi <stefanha at gmail.com>:
> On Thu, Jan 14, 2010 at 2:35 PM, Joshua Oreman <oremanj at rwcr.net> wrote:

>> Keep in mind that gPXE has extremely limited code size constraints; I
>> suspect this is why Stefan didn't want to use an actual process for
>> the TFTP fix when something lighter-weight would do.
>
> Yes.  I like the idea of a wait queue, it's a powerful primitive.
> However it is not essential to have it, and that's how gPXE manages to
> pack so much punch into 64 KB - it focuses on the essentials.

I think it could probably be done in a way that would actually reduce
overall code size, since it would simplify other parts of the code.
However, it's a big project to get it right and implement it
everywhere, so even if it's useful maybe it's something for another
day :)

Your patch certainly fixes the issue of DNS lookup stalling the
beginning of the transfer.

>> My opinion on the
>> ARP issue: it's only going to get hit once per TFTP server, which is a
>> lot less than once per file, and can probably be ignored barring
>> evidence to the contrary.
>
> Good point.  Our ARP cache never expires entries.

If only one TFTP server is used then the delay from ARP lookup is only
400ms overall, that's not a lot, but should that packet get lost some
other way the delay increases again, so it's not ideal. If send()
could return an error if the ARP lookup had to be kicked off we could
handle it the same way with start_timer_nowait() and the delays would
be completely eliminated. I'll probably have a look over the weekend.

By the way both the qemu patches for tftp have been committed upstream
so if you get qemu from head you should be able to test everything
working nicely together.

Thomas