Cached IP routes

[Andre Oppermann]

Ruslan Ermilov wrote:
> 
> Andre,
> 
> I see you've fixed ip_forward() so that it no longer caches (possibly
> stale) route, which is great.  What are the performance impacts of this
> change, have you measured it?

I've removed the "route cache" in ip_forward() mainly because it was
a major headache for the locking code.  I have not measured the impact.
However this cache was only caching the last used route.  If you only
have a default route the routing table is so small that a normal routing
table lookup is extremely fast as well.  If you have a full default free
view of the Internet and push a lot of traffic then it becomes highly
unlikely that two packet following each other use the same route.  If
that happens you have pessimized more than without this route cache
because it needs to free the preview entry first.  In the end the
performance trade-off is essentially equal but without the route cache
it's much simpler and less complexity.

> We still have a similar problem in in_gif_output(), and I wonder what
> would be a correct fix, given the above?

in_gif_output() is not the same as the route cache of ip_forward.  It
just caches the route to the tunnel destination which normally stays
the same over long periods of time.  The only problem you might run
into are route changes.  At one point in time your best path is the
default route so a pointer to it is being cached in sc->gif_ro.  Later
you have a better via some other gateway.  This won't be picked up by
the gif route cache.  In 5.2 and -CURRENT you can scrap the route
cache and just give a NULL to ip_output instead of a route.  This way
you will always use the best path to destination.

-- 
Andre