ftp://ftp.netbsd.org/pub/NetBSD/misc/joerg/rtcache2.diff

> This is part one to actually do this. The difference to David's approach
> is that I want to actually abstract the route cache (re)validation and
> ultimately avoid doing the domain specific flushing.

This contains everything from the first patch and replaces David's patch
with invalidation of directly covered routes.

The idea is that the routing is changed by one of two events:
(a) When a route gets removed. This case was already handled by removing
the RTF_UP flag, but it was not always checked correctly.
(b) When a route gets added. Cached routes of the parent (aka the most
specific route covering the full range of the newly added route) could
now be invalid. Consider an open connection 204.152.184.36 using the
default route. When I now add 204.0.0.0/8 to the routing table, the
cached route of the connection is stale. The patch addresses this by
looking for the parent route and forcing a copy of it. If it is cached,
the old version will still be kept in the routing table until the users
check the validity the next time. For TCP this happens at send time. Now
the route is found invalid (missing RTF_UP flag) and looked up again.
Either the new route or the copy is found and everything is happy again.

The changes to route.c and radix.c need careful review -- the code is
obnoxious. It does have the big advantage of not requiring a full
iteration over all PCBs when a route is added. The cost is amortised
over normal traffic processing.

Joerg