[U-Boot] http client?

[jeffery palmer]

I played around with setting the TFTP block size very large, like 16K,
primarily to reduce the required number of ACK's. It actually appeared as
though uboot was processing the additional frames correctly but without
doing a memory comparison I'm not sure. Here were a few bad side effects
though...
	- blksize set to 16K, when fetching a 10 byte file it thinks it's
downloading a 6000 byte file
	- The last packet appears to mess things up. The majority of the
transfer goes very well and then at the very end it hangs. Likely the
portion of tftp.c that checks when the file is completed.

UDP packets are either not fragmented or very easy to re-assemble. When
doing a tcpdump the udp packets go out as 1500 byte chunks. A 16K tftp block
gets broken into 11 consecutive packets and requires only 1 ACK. Because
packets can come in out of order and uboot is not very network oriented, I
would suggest just dumping the entire block if a packet comes in out of
order and re-request that block.

Anyways, you can jump right in by setting the blksize to a large number and
see how it behaves.

> > When I looked at the RFC data
> > it appears that the overhead of IP fragmentation and reassembly 
> > (which does add overhead as the number of gateways increases) may be 
> > worth the time...
> 
> Just tried it: U-Boot doesn't support reassembly, it seems.

I don't think anyone said it did.

> net.c confirms it:
> 
>                 /* Can't deal with fragments */
>                 if (ip->ip_off & htons(IP_OFFS | IP_FLAGS_MFRAG)) {
>                         return;
>                 }
> 
> I don't think it's worth adding.

This is based on ... ?

If it reduces download time by 1/2 (1432 byte block size == 13.70 seconds,
4096 byte block size == 6.85 seconds) it might be worth the complexity...

At least worth it enough to give it a try, gather some results, and then
make a decision.

-Robin