From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 15:30:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DBF16A421 for ; Wed, 22 Aug 2007 15:30:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id DA5DC13C4DA for ; Wed, 22 Aug 2007 15:30:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1E0BA23682; Wed, 22 Aug 2007 11:30:36 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 22 Aug 2007 11:30:36 -0400 X-Sasl-enc: 6WVZjMpXUOsQWZTDo2SNLo6+AAa1RXMJgNT1NSywhQWh 1187796635 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id AB63813AD1; Wed, 22 Aug 2007 11:30:35 -0400 (EDT) Message-ID: <46CC5698.7090200@FreeBSD.org> Date: Wed, 22 Aug 2007 16:30:32 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivo Vachkov References: <46CC475F.8030505@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2007 15:30:37 -0000 Ivo Vachkov wrote: > Actually there is: > > struct route_in6 ip6_forward_rt; > > that "caches" the last route used (thanks blue !!!) but i think this > technique is pointless in a multiflow traffic. > Yes, this is why OpenBSD got rid of this form of 'route caching'. > Is it reasonable to believe that route caches can improve networking > performance or we should leave it up to the routing table itself ? > I believe that if one goes beyond a single radix trie, as is needed for multi-pathing with multicast and source policy routing, route caching is *required* to achieve good performance. Also, if FreeBSD moves ARP and NDP out of the radix trie, a route cache would be highly preferable as it amortizes the lock acquisition which would other be required for ARP/NDP/other layer 2 next-hop resolution. BMS