Richard A Steenbergen wrote: > On Thu, May 30, 2002 at 11:46:21AM +0200, Andre Oppermann wrote: > > The theorie about the LC-Trie is that it'll fit into L2 cache for the > > entire default-free forwarding table. > > Versus the reality of doing bit operations instead of byte operations. In > my tests, the mtrie was always faster, even on a celeron with a piddly L2 > cache.
We'll find out. We're designing a framework into which different kinds of tables can be implemented. We can move on to profiling then. > > This might work on a decicated router system. FreeBSD is being used > > for servers as well. > > Please explain how that would not work for servers? It would work but not optimal because the packet flow is different for locally terminated/generated packets. > > Also to not to change the userland/kernel interface wrt routing we have > > to keep all prefixes in the kernel RIB. This means we have to be able to > > do longest prefix matching. > > This is a non sequitur. All routes will be available through the kernel > RIB, but for exact matches only. When is a longest prefix match needed > there? When the routing daemon instructs us to remove the prefix 10.0.0.0/8 when we also have 10.0.0.0/9 and 10.128.0.0/9. > > Anyway, I'm confident we'll come up with something that is well > > balanced and much faster and more memory conserving than what we > > have today with the patricia trie. (A default-free kernel RIB consumes > > approx. 30MB of kernel memory in 4-STABLE/5-CURRENT at the moment). > > Not to mention the outrageous amounts of memory consumed by the caching > mechanism. Where? Do you mean rt_metrics? > Oh, and it should be able to support multiple nexthops per prefix, and > load balance across them. I think even Linux has this support now, and an > actual FIB. Yes, and policy routing... -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
