From owner-freebsd-net@FreeBSD.ORG Mon Mar 8 03:56:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D8A316A4CE for ; Mon, 8 Mar 2004 03:56:32 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 979D043D1D for ; Mon, 8 Mar 2004 03:56:31 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 72765 invoked from network); 8 Mar 2004 11:56:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Mar 2004 11:56:30 -0000 Message-ID: <404C5F65.446E20A8@freebsd.org> Date: Mon, 08 Mar 2004 12:56:21 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov References: <20040308102038.GA28502@ip.net.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@FreeBSD.org Subject: Re: Cached IP routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2004 11:56:32 -0000 Ruslan Ermilov wrote: > > Andre, > > I see you've fixed ip_forward() so that it no longer caches (possibly > stale) route, which is great. What are the performance impacts of this > change, have you measured it? I've removed the "route cache" in ip_forward() mainly because it was a major headache for the locking code. I have not measured the impact. However this cache was only caching the last used route. If you only have a default route the routing table is so small that a normal routing table lookup is extremely fast as well. If you have a full default free view of the Internet and push a lot of traffic then it becomes highly unlikely that two packet following each other use the same route. If that happens you have pessimized more than without this route cache because it needs to free the preview entry first. In the end the performance trade-off is essentially equal but without the route cache it's much simpler and less complexity. > We still have a similar problem in in_gif_output(), and I wonder what > would be a correct fix, given the above? in_gif_output() is not the same as the route cache of ip_forward. It just caches the route to the tunnel destination which normally stays the same over long periods of time. The only problem you might run into are route changes. At one point in time your best path is the default route so a pointer to it is being cached in sc->gif_ro. Later you have a better via some other gateway. This won't be picked up by the gif route cache. In 5.2 and -CURRENT you can scrap the route cache and just give a NULL to ip_output instead of a route. This way you will always use the best path to destination. -- Andre