[U-Boot] [PATCH 1/3] net: defragment IP packets

[Robin Getz]

On Fri 31 Jul 2009 03:46, Alessandro Rubini pondered:
> > For some reason - why I'm ping flooding when tftping a large file 
> > (with large tftp block size) - things hang. If I set the block size
> > to under the MTU - it  works fine. Do you get the same?
> 
> Didn't try, and I can't do that today. I suspect either your ping is
> over-mtu, so each new fragment triggers the above code,

No ping is the default length. The default packet size is 56 bytes, which 
translates into 98 bytes on the wire (8 bytes of ICMP header data, 20 for the 
IP header, and another 14 for the MAC addresses)

> or simply your 
> ether+uboot can't keep up with the data rate.

That doesn't explain, why does it work, when there is no fragmentation???

What it looks like is there is something wrong with the main network loop - 
the system is so busy responding to pings, that it never sends the TFTP Block 
ACK when it should.

> As eaplained in the cover letter <cover.1248943812.git.rubini at unipv.it>
> some fragments can be lost in high traffic, as polling mode doesn't allow
> to enqueue packets.  So I think you just loose some fragments, as target
> CPU time is eaten by the ping packets, and you don't get the complete
> reassembled packet any more.
>
> I'm pretty sure it's like this.

I'm not convinced yet - but need to do some further poking on a different 
network...

> On the other hand, I found a minor issue in this situation:
> 	- start a tftp transfer
> 	- ctrl-C it
> 	- start another
> 
> Server retransmissions for the first transfer go into the defrag
> engine e that reset-defrag-data code is triggered, so a packet may be
> lost, and I get a sporadic T in the receiving u-boot.  I think it's
> not a real problem, though --- or, now that I rethink about it, it
> can be the same issue as above: my ether can't enqueue 8k of stuff
> so a fragment is lost in that case.  

What is missing in the reassembly code (that is described in RFC815) is the 
timer. (quote from the RFC):
--------------
The  final  part  of  the  algorithm  is  some  sort of timer based
mechanism which decrements the time to  live  field  of  each  partially
reassembled  datagram,  so that incomplete datagrams which have outlived
their usefulness can be detected and deleted.
--------------