Route caching ?

[Andre Oppermann]

Bruce M. Simpson wrote:
> 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'.

If you have a single flow a radix trie doesn't perform less good than
a cache as all nodes are in the CPU cache anyway.

>> 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.

No, most likely not.  Caching only adds a lot of complexity.  All
useful caching is already done by the CPU caches.  You almost can't
do better than that.

> 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.

Route caching has some side evilness other than being ineffective.
For every route change you either have to invalidate the entire
cache or you have to do a cache lookup on all CPUs (if you have one
per CPU as you seem to suggest) to prevent it from using stale data.
If you don't use BGP DFZ sized routing tables caching is pointless
anyway.  If you do, you get some 1k updates per minute.  Lots of
cache invalidations.  Multi-CPU cache invalidation has big locking
implications which makes it inefficient again.

There is not really much to win with route caching other than a huge
amount of unnecessary complexity.

-- 
Andre