From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 17:13:22 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 29E9116A41A for ; Wed, 22 Aug 2007 17:13:22 +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 E176513C457 for ; Wed, 22 Aug 2007 17:13:21 +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 65B92255C7; Wed, 22 Aug 2007 13:13:21 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 22 Aug 2007 13:13:21 -0400 X-Sasl-enc: GWYHVALrOxgVPSjf8lirsUpbn4cOiALcu9Hz49Ucq3x5 1187802801 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 D6857231E5; Wed, 22 Aug 2007 13:13:20 -0400 (EDT) Message-ID: <46CC6EAF.3010003@FreeBSD.org> Date: Wed, 22 Aug 2007 18:13:19 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Claudio Jeker , freebsd-net@freebsd.org References: <46CC475F.8030505@FreeBSD.org> <20070822151228.GB22194@diehard.n-r-g.com> In-Reply-To: <20070822151228.GB22194@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 17:13:22 -0000 Claudio Jeker wrote: > Just because you believe that route caches are great doesn't mean it is > true. Show some real code and include benchmarks with various workloads > (e.g. a core router that is hit by many many many sessions). > It is a reasonable approach, for a uniprocessor design, to focus on optimizing the route lookup as much as possible. Does this approach scale to SMP, though? This is still a very much open question and from what I have seen of the OpenBSD implementation, it only addresses the uniprocessor case - again please correct me here if I have missed any details. I believe the Linux dst cache is strongly tied to the IBM-patented Remote-Copy-Update algorithm based on what I've read about their LC-trie implementation. > Until now all caching solutions resulted in very bad performance on busy > boxes. Remember ip_fastforward or how was it called? Another example are > all crapy L3 switches that burn down if the CAM (chache) is flodded. > I assume you are referring to NetBSD's flow-based IP forwarding cache, which was implemented outside of the scope of SMP; spl-style interrupt priority masking was still in use at that time. It is established that saturating content-addressable memory is going to lead to the slow path being taken, however, that's the trade-off one makes with these designs. > IMO it is better to make the route lookup faster and forget about caching. > My concern is that you may be comparing apples with oranges here. In the case of SMP, locking does become a consideration, and caches, if carefully implemented, are one way of addressing this. On the other hand, CPU affinity has been proposed as a limited solution, however it depends how this is implemented - affinity for lookups, forwarding, or both? Perhaps there is something I am missing about how the OpenBSD implementation deals with SMP, as I am not as familiar with their code as FreeBSD's. regards, BMS