From owner-freebsd-net Thu May 30 8:22:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id C806137B406 for ; Thu, 30 May 2002 08:22:28 -0700 (PDT) Received: (qmail 34905 invoked from network); 30 May 2002 15:22:08 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 30 May 2002 15:22:08 -0000 Message-ID: <3CF6436D.ADA51D7F@pipeline.ch> Date: Thu, 30 May 2002 17:21:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard A Steenbergen Cc: "Louis A. Mamakos" , Attila Nagy , Luigi Iannone , freebsd-net@FreeBSD.ORG Subject: Re: MPLS References: <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net> <3CF51E7C.E9A47960@pipeline.ch> <20020529233411.GO33611@overlord.e-gerbil.net> <3CF5F4ED.369BCE83@pipeline.ch> <20020530150612.GP33611@overlord.e-gerbil.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message