Date: Sat, 04 Dec 2004 21:02:46 +0100 From: Andre Oppermann <andre@freebsd.org> To: netch@lucky.net Cc: net@freebsd.org Subject: Re: route cacheing for gif(4) should be optional Message-ID: <41B217E6.BB95770E@freebsd.org> References: <20041125140641.GA78210@cell.sick.ru> <20041126025510.GA44246@scylla.towardex.com> <20041126091316.GA84369@cell.sick.ru> <41AB3CB9.598BB2FB@freebsd.org> <20041129161529.GA4770@cell.sick.ru> <20041204191508.GA18236@lucky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Valentin Nechayev wrote: > > Hi, > > Mon, Nov 29, 2004 at 19:15:29, glebius wrote about "Re: route cacheing for gif(4) should be optional": > > A>> However there have been reasons for > A>> storing the rtentry pointer in struct gif. In the old days ip_output() > A>> required an rtentry pointer to be passed on, this is no longer the case. > A>> And it was sort of a safe-guard to make it harder to send the gif encapsulated > A>> packets back through the same gif interface. That didn't work really well > A>> and as I say it should be scapped instead of rigged on somewhere else with > A>> yet another obscure option. ;) > > > As soon as I make route cacheing optional, I'd like to make it off by default. > > Let me explain: FreeBSD is stable by default, not fast. Routecacheing is not stable. > > When a route flap occurs in dynamicly routed network my gif tunnels are stuck. > > I'll describe in manpage, that more performance can be achieved by enabling this > > route cacheing. Any objections on this default? > > Tracking Cisco & etc. footsteps, there is yet another variant: add cached > route with aging and set default aging time very small (e.g. 1 sec). > This can give preferences of caching among with satisfactory time of renewal. > I think this will be best variant, but if in a case it isn't adoptable, > let's caching will be disabled totally by default. Tracking Cisco is not really a recommended practice. They make tons of hacks, work-arounds and other non-intelligent things to work around problems in their platforms. Working with Cisco gear is not a really a pleasure and finding an IOS version that not advertises it can do X but actually does it without introducing yet another bug somewhere else is like playing lottery. Cisco is no longer the holy grail of high performance routing nor has is been for quite some time. This route cache thing is pretty much a non-issue. While a route cache may make some sense for a gif tunnel (very high probability of using the same route) it introduces a lot of synchronization and locking issues with the routing table code. Once up on a time every TCP connection used to cache a pointer to its route. It became a locking nightmare and I threw it out. If we are talking about a multi-gigabit gif tunnel server then I'd agree that we need some form of optimzation. But for everything it's simply not going to make a difference. Doing a route lookup is fast enough for any normal use. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41B217E6.BB95770E>