From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Robert Olsson <Robert.Olsson@data.slu.se>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [IPV4 0/9] TRIE performance patches
Date: Wed, 23 Jan 2008 15:49:33 -0800 [thread overview]
Message-ID: <20080123154933.233c4909@deepthought> (raw)
In-Reply-To: <18327.18935.137799.285515@robur.slu.se>
On Wed, 23 Jan 2008 15:06:47 +0100
Robert Olsson <Robert.Olsson@data.slu.se> wrote:
>
> Stephen Hemminger writes:
>
> > Time to handle a full BGP load (163K of routes).
> >
> > Before: Load Dump Flush
> >
> > kmem_cache 3.8 13.0 7.2
> > iter 3.9 12.3 6.9
> > unordered 3.1 11.9 4.9
> > find_node 3.1 0.3 1.2
>
> I certainly like the speed but what will we brake when
> we don't return in longest prefix order?
>
> labb:/# ip r
> default via 10.10.10.1 dev eth0
> 5.0.0.0/8 via 192.168.2.2 dev eth3
> 10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.2
> 10.10.11.0/24 dev eth1 proto kernel scope link src 10.10.11.1
> 11.0.0.0/8 via 10.10.11.2 dev eth1
> 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.2
> 192.168.2.0/24 dev eth3 proto kernel scope link src 192.168.2.1
>
> labb:/# ip route list match 10.10.10.1
> default via 10.10.10.1 dev eth0
> 10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.2
> labb:/#
>
> Maybe the unordered dump can be ordered cheaply...
Dumping by prefix is possible, but unless 32x slower. Dumping in
address order is just as logical. Like I said, I'm investigating what
quagga handles.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
next prev parent reply other threads:[~2008-01-23 23:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-22 23:37 [IPV4 0/9] TRIE performance patches Stephen Hemminger
2008-01-22 23:37 ` [IPV4 1/9] fib_trie: put leaf nodes in a slab cache Stephen Hemminger
2008-01-22 23:37 ` [IPV4 2/9] fib_trie: style cleanup Stephen Hemminger
2008-01-22 23:37 ` [IPV4 3/9] fib_trie: compute size when needed Stephen Hemminger
2008-01-22 23:37 ` [IPV4 4/9] fib_trie: use hash list Stephen Hemminger
2008-01-22 23:37 ` [IPV4 5/9] fib_trie: dump message multiple part flag Stephen Hemminger
2008-01-22 23:37 ` [IPV4 6/9] fib_trie: iterator recode Stephen Hemminger
2008-01-22 23:37 ` [IPV4 7/9] fib_trie: dump table in sorted order Stephen Hemminger
2008-01-22 23:37 ` [IPV4 8/9] fib_trie: avoid extra search on delete Stephen Hemminger
2008-01-22 23:37 ` [IPV4 9/9] fib_trie: avoid rescan on dump Stephen Hemminger
2008-01-23 5:58 ` [IPV4 0/9] TRIE performance patches David Miller
2008-01-23 14:06 ` Robert Olsson
2008-01-23 16:31 ` Stephen Hemminger
2008-01-23 23:49 ` Stephen Hemminger [this message]
2008-01-24 9:36 ` Robert Olsson
2008-01-24 16:18 ` Stephen Hemminger
2008-02-01 18:00 ` Robert Olsson
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=20080123154933.233c4909@deepthought \
--to=shemminger@linux-foundation.org \
--cc=Robert.Olsson@data.slu.se \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).