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 08:31:05 -0800 [thread overview]
Message-ID: <47976BC9.3020801@linux-foundation.org> (raw)
In-Reply-To: <18327.18935.137799.285515@robur.slu.se>
Robert Olsson 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...
>
> Cheers.
> --ro
>
>
Hash returned the routes in prefix order (then random). Returning the
routes in numerical order
seems just as logical. I'm going to test on quagga.
next prev parent reply other threads:[~2008-01-23 16:30 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 [this message]
2008-01-23 23:49 ` Stephen Hemminger
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=47976BC9.3020801@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.