From: Alessandro Rubini <rubini-list@gnudd.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] net: defragment IP packets
Date: Fri, 31 Jul 2009 14:16:33 +0200 [thread overview]
Message-ID: <20090731121633.GA16411@mail.gnudd.com> (raw)
In-Reply-To: <200907310750.55715.rgetz@blackfin.uclinux.org>
>> 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
next prev parent reply other threads:[~2009-07-31 12:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 9:02 [U-Boot] [PATCH 0/3] Defragment IP packets Alessandro Rubini
2009-07-30 9:02 ` [U-Boot] [PATCH 1/3] net: defragment " Alessandro Rubini
2009-07-30 9:03 ` [U-Boot] [PATCH 2/3] tftp: get the tftp block size from config file and from the environment Alessandro Rubini
2009-07-30 9:03 ` [U-Boot] [PATCH 3/3] arm nomadik: select defrag and 4k tftp block size Alessandro Rubini
[not found] ` <8124a390e4cbcfee291c7583a585c9d030aadf7a.1248943812.git.rubini @unipv.it>
2009-07-30 9:25 ` [U-Boot] [PATCH 2/3 V2] tftp: get tftpblocksize from cfg file and env Alessandro Rubini
[not found] ` <7b8035d1-8543-4b85-ba00-ac21ff1a60df@lists.denx.de>
2009-07-30 23:15 ` [U-Boot] [PATCH 1/3] net: defragment IP packets Robin Getz
2009-07-31 7:46 ` Alessandro Rubini
2009-07-31 11:50 ` Robin Getz
2009-07-31 12:16 ` Alessandro Rubini [this message]
2009-07-31 13:40 ` Robin Getz
2009-07-31 14:02 ` Alessandro Rubini
2009-07-31 15:14 ` Robin Getz
2009-07-31 15:44 ` Alessandro Rubini
2009-07-31 15:33 ` Robin Getz
2009-08-05 16:59 ` Robin Getz
2009-08-05 17:18 ` Alessandro Rubini
2009-08-05 17:24 ` Ben Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090731121633.GA16411@mail.gnudd.com \
--to=rubini-list@gnudd.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox