From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alessandro Rubini Date: Fri, 31 Jul 2009 14:16:33 +0200 Subject: [U-Boot] [PATCH 1/3] net: defragment IP packets In-Reply-To: <200907310750.55715.rgetz@blackfin.uclinux.org> References: <200907310750.55715.rgetz@blackfin.uclinux.org> <200907301915.16104.rgetz@blackfin.uclinux.org> <7b8035d1-8543-4b85-ba00-ac21ff1a60df@lists.denx.de> <20090731074613.GA11803@mail.gnudd.com> Message-ID: <20090731121633.GA16411@mail.gnudd.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >> 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