[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080123154933.233c4909@deepthought>
Date: Wed, 23 Jan 2008 15:49:33 -0800
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: Robert Olsson <Robert.Olsson@...a.slu.se>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [IPV4 0/9] TRIE performance patches
On Wed, 23 Jan 2008 15:06:47 +0100
Robert Olsson <Robert.Olsson@...a.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@...tta.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists