| |
Check the routing table is fast? Or check the socket hash table fast? This is simply not a problem. The fundamental problem is how to effectively use both, so that the two become partners rather than competitors. How is this going?
We know that if a packet destined for a local, then it has to go through the discovery process twice (not to consider conntrack): IP layer and the transport layer routing lookup to find socket. How to merge the two.
Linux kernel stack is a way: Add a dst field as a means in the socket buffer route, skb first look at the routing socket before, to find the words, it will be set to the cache dst skb, the next in the routing of I found have dst, eliminating the need for routing lookup process.
The question is, when dst field socket set it? Of course, is "the first and the socket skb relevant" comes, even if it is no doubt the first skb found on the socket set, dst socket on this case is NULL, then it will look for the route to be honest table, if found, will find the routing entry is set to dst field of socket.
This feature is called ip_early_demux implementation in Linux, the kernel document, described as follows:
ip_early_demux - BOOLEAN Optimize input packet processing down to one demux for
certain kinds of local sockets. Currently we only do this
for established TCP sockets.
It may add an additional cost for pure routing workloads that
reduces overall throughput, in such case you should disable it.
Default: 1
For forward forwarding, this feature is bound to reduce the performance, but I do not want to say the obvious question, I want to say two things:
1. The logic level cache
We know that the route is to find a "best effort" many-matching process, skb, and routing entry is not a precise one relationship, it is not cached in the routing entry in the socket, but the socket can be cached in the routing entry because the socket and skb is a one to one relationship (I do not mean TCP listen socket ..), similarly, I can cache socket in the routing cache, since the routing cache and skb is one to one relationship.
However, Linux kernel support routing cache was removed, but it does not matter, as long as it is enough to know: can accurately match one to one non-cached looser one to one match. If you look to move conntrack, you know how to do it, I had the route cache entry to the conntrack inside, according to this logic, it is reasonable, the same, socket can also be cached in the conntrack inside, which have iptables relevant match and target.
2. Automatic or manual
Since Linux has ip_early_demux configuration parameters, the question is when to turn it on and when to turn it off. In particular, in the case you do not know in advance how many packets reach the local, how many packets are forward in the case, the problem is even more difficult to answer. At this point, I believe is either 0 or 1 configuration it, or allow the system administrator to dynamically adaptive?
How statistical package is particularly important, typically, if there are more than 60% of the package is to reach the local, then open it, close it and vice versa. ip_early_demux configuration parameters as a global parameter and there is nothing bad, because if not, then there will be another problem, namely, how to determine whether a packet to be early_demux ... for seven non-boundary facilities, in general, traffic is classified, divided management plane traffic and data plane traffic, for the former, the end of the traffic is local, and for the latter, this machine only do forward, if we can advance efficiently classify packets plane, then two a ip_early_demux configuration will look better for the band management is concerned, Linux is nsnamespace can accomplish this task very well. |
|
|
|