Route caching ?

[Bruce M. Simpson]

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