Date: Wed, 22 Aug 2007 18:13:19 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Claudio Jeker <cjeker@diehard.n-r-g.com>, freebsd-net@freebsd.org Subject: Re: Route caching ? Message-ID: <46CC6EAF.3010003@FreeBSD.org> In-Reply-To: <20070822151228.GB22194@diehard.n-r-g.com> References: <f85d6aa70708220003le893770uca9ceea467d85618@mail.gmail.com> <46CC475F.8030505@FreeBSD.org> <f85d6aa70708220737p28fb6260h699754544ccd249a@mail.gmail.com> <20070822151228.GB22194@diehard.n-r-g.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46CC6EAF.3010003>