Hi Dave:
This series of patches will be dedicated to the routing cache.
Before I start working on the routing cache itself, I need to fix
some of the issues with the multipath caching code (it happens to
be in the critical places where I'll be changing the code).
I've already sent you one patch that disables the multipath cache
addition on the input path until we actually start using it.
The next problem I'm going to tackle is to do with how the multipath
cache entries are handled.
Currently they're added one by one and live a semi-independent life
once they're in the cache.
This is buggy since two CPUs could both get a routing cache miss and
then decide to add the multipath entries for the same route. We will
then end up with two copies of the same route.
The solution is to create them all and then insert them all at once.
However, the fact that one route can now spawn a large number of
routing entries on the chain is bad for chain length management
since
1) It may look like hash collision when it isn't.
2) It means that we have to walk over more entries when there is a collision.
The solution is to put the multipath entries of the same route onto
its own linked list and only link the head of the list into the routing
cache.
This solution requires the addition of a new pointer into rtable.
Well I felt guilty for doing that so that's why I'm sending you this
patch :)
This rearranges dst_entry so that we shave off 8 bytes on 64-bit
platforms when CLS_ROUTE is enabled.
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
I'll rearrange rtable next which will save us some more.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
route-2
Description: Text document
|