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

Alessandro Rubini rubini-list at gnudd.com
Fri Jul 31 14:16:33 CEST 2009


>> 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???

Well, with no fragmentation there is less traffic. Each tftp packet is
one patch, instead of a burst of packets (intermixed with pings).

Is the target replying to all pings? Or is it loosing some?
If it looses say 30%, I expect one fragment in 3 to be lost as well.
If your big-tftp is 4 fragments, 20% passes it loss is equally spread ((2/3)^4),
but I fear much less as the burst saturates the incoming queue. 

>> I'm pretty sure it's like this.
> 
> I'm not convinced yet - but need to do some further poking on a different 
> network...

Thanks for these tests, mine is just guessing.

> 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.
> --------------

But I reassemble one packet only, so I don't need to timeout
partly-filled packets to recover memory. A soon as I have a fragment
for a new packet, the old packet is discarded (while unfragmented stuff
flies intermixed).

/alessandro


More information about the U-Boot mailing list