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

[Robin Getz]

On Fri 31 Jul 2009 08:16, Alessandro Rubini pondered:
> >> 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? 

Yes. And I can see the same in wireshark.

> Or is it loosing some? 

No.

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

No problem. I want to make sure it is robust as well.

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

But it is for the state that you described - the user cntr-C a current 
transfer, and the reassembly algorithm doesn't know to throw away a partially 
accepted packet, when things are cancelled...

> A soon as I have a fragment for a new packet, the old packet is 
> discarded (while unfragmented stuff flies intermixed).

Which works when you receive a complete fragment.

As you indicated - what really happens is it causes a timeout on the first 
packet. Up to you if you want to handle this or not...

All that should be needed is just to clear things in the start of NetLoop() 
(before eth_init) - there are a few things in there for CONFIG_NET_MULTI 
already, so I don't think that is a big deal... (That becomes your timer - a 
one shot at the very beginning of the transfer :)

-Robin