Date: Thu, 30 May 2002 11:06:12 -0400 From: Richard A Steenbergen <ras@e-gerbil.net> To: Andre Oppermann <oppermann@pipeline.ch> Cc: "Louis A. Mamakos" <louie@TransSys.COM>, Attila Nagy <bra@fsn.hu>, Luigi Iannone <Luigi.Iannone@lip6.fr>, freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <20020530150612.GP33611@overlord.e-gerbil.net> In-Reply-To: <3CF5F4ED.369BCE83@pipeline.ch> References: <Pine.LNX.4.44.0205291108080.7798-100000@scribble.fsn.hu> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 30, 2002 at 11:46:21AM +0200, Andre Oppermann wrote: > > Flow has its benefits, such as netflow export, and maybe even at some > > point it could be tied into ipfw to improve performance... I'd like to see > > it stay around as a route-cache method, but probably not in its current > > form. > > I don't know if you have looked at the flow in code in FreeBSD but > it's nowhere near what you'd expect from something that should do > Netflow. IPFW has already something like that, it's called dynamic > rules for TCP streams. On the other hand, to get performace you'd > have to rewrite ipfw by a great deal or switch to OpenBSDs pf. Yes I know, thats why I said "probably not in its current form". Just suggesting that instead of gutting it completely, it be updated to something a little more useful. This is pretty trivial, I did such a while back but I lost the patch in a drive failure. :) > 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. > 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? > 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? > 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. 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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020530150612.GP33611>