The routing cache has been suppressed in Linux 3.6 after a 2 years effort by David and the other Linux kernel developers.
The global cache has been suppressed and some stored information have been moved to more separate resources like socket.
Metrics were stored in the routing cache entry which has disappeared. So it has been necessary to introduce a separate TCP metrics cache.
A netlink interface is available to update/delete/add entry to the cache.
当内核接收到一个TCP数据包来说，首先需要查找skb对应的路由，然后查找skb对应的socket。David Miller 发现这样做是一种浪费，对于属于同一个socket(只考虑ESTABLISHED情况）的路由是相同的，那么如果能将skb的路由缓存到socket（skb->sk)中，就可以只查找查找一次skb所属的socket，就可以顺便把路由找到了，于是David Miller提交了一个patch ipv4: Early TCP socket demux
ipv4: Early TCP socket demux.
Input packet processing for local sockets involves two major demuxes.
One for the route and one for the socket.
But we can optimize this down to one demux for certain kinds of local
Currently we only do this for established TCP sockets, but it could
at least in theory be expanded to other kinds of connections.
If a TCP socket is established then it's identity is fully specified.
This means that whatever input route was used during the three-way
handshake must work equally well for the rest of the connection since
the keys will not change.
Once we move to established state, we cache the receive packet's input
route to use later.
Like the existing cached route in sk->sk_dst_cache used for output
packets, we have to check for route invalidations using dst->obsolete
Early demux occurs outside of a socket locked section, so when a route
invalidation occurs we defer the fixup of sk->sk_rx_dst until we are
actually inside of established state packet processing and thus have
the socket locked.
This change is meant to add a control for disabling early socket demux.
The main motivation behind this patch is to provide an option to disable
the feature as it adds an additional cost to routing that reduces overall
throughput by up to 5%. For example one of my systems went from 12.1Mpps
to 11.6 after the early socket demux was added. It looks like the reason
for the regression is that we are now having to perform two lookups, first
the one for an established socket, and then the one for the routing table.
By adding this patch and toggling the value for ip_early_demux to 0 I am
able to get back to the 12.1Mpps I was previously seeing.