[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