标签：
繁忙了一整天，下班回家总会有些许轻松，这是肯定的。时间不等人，只要有剩余的时间，就想来点自己喜欢的东西。下班的班车上，用手机那令人遗憾的屏幕目睹了Linux 4.6的一些新特性，让我感兴趣的有两点，第一是关于reuseport的，这也是本文要阐释的，另外一个是关于KCM(Kernel Connection Multiplexor)的，而这个是我本周末计划要写的内容，这些都是回忆，且都是我本身经历过的，正巧天气预报说今晚有暴雨，激起了一些兴趣，于是信手拈来，不足之处或者写的不明之处，还望有人可以指出。我想从Q&A说起，这也符合大众的预期，如果你真的能理解我的Q&A想说什么，那么Q&A之后接下来的内容，不看也罢。 result = NULL;
badness = 0;
udp_portaddr_for_each_entry_rcu(sk, node, &hslot2->head) {
score = compute_score2(sk, net, saddr, sport,
daddr, hnum, dif);
if (score > badness) { // 冒泡排序
// 找到了更加合适的socket，需要重新hash
result = sk;
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
hash = udp_ehashfn(net, daddr, hnum,
saddr, sport);
matches = 1;
}
} else if (score == badness && reuseport) { // reuseport套接字散列定位
// 找到了同样reuseport的socket，进行定位
matches++;
if (reciprocal_scale(hash, matches) == 0)
result = sk;
hash = next_pseudo_random32(hash);
}
} result = NULL;
badness = 0;
udp_portaddr_for_each_entry_rcu(sk, node, &hslot2->head) {
score = compute_score2(sk, net, saddr, sport,
daddr, hnum, dif);
if (score > badness) {
// 在reuseport情形下，意味着找到了更加合适的socket组，需要重新hash
result = sk;
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
hash = udp_ehashfn(net, daddr, hnum,
saddr, sport);
if (select_ok) {
struct sock *sk2;
// 找到了一个组，接着进行组内hash。
sk2 = reuseport_select_sock(sk, hash, skb,
sizeof(struct udphdr));
if (sk2) {
result = sk2;
select_ok = false;
goto found;
}
}
matches = 1;
}
} else if (score == badness && reuseport) {
// 这个else if分支的期待是，在分层查找不适用的时候，寻找更加匹配的reuseport组，注意4.5/4.6以后直接寻找的是一个reuseport组。
// 在某种意义上，这回退到了4.5之前的算法。
matches++;
if (reciprocal_scale(hash, matches) == 0)
result = sk;
hash = next_pseudo_random32(hash);
}
}struct sock *reuseport_select_sock(struct sock *sk,
u32 hash,
struct sk_buff *skb,
int hdr_len)
{
...
prog = rcu_dereference(reuse->prog);
socks = READ_ONCE(reuse->num_socks);
if (likely(socks)) {
/* paired with smp_wmb() in reuseport_add_sock() */
smp_rmb();
if (prog && skb) // 可以用BPF来从用户态注入自己的定位逻辑，更好实现基于策略的负载均衡
sk2 = run_bpf(reuse, socks, prog, skb, hdr_len);
else
// reciprocal_scale简单地将结果限制在了[0,socks)这个区间内
sk2 = reuse->socks[reciprocal_scale(hash, socks)];
}
...
}#define MAX 18 struct sock *reusesk[MAX];每当OpenVPN创建一个reuseport的UDP套接字的时候，我会将其顺序加入到reusesk数组中去，最终的查找算法修改如下：
result = NULL;
badness = 0;
udp_portaddr_for_each_entry_rcu(sk, node, &hslot2->head) {
score = compute_score2(sk, net, saddr, sport,
daddr, hnum, dif);
if (score > badness) {
result = sk;
badness = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
hash = inet_ehashfn(net, daddr, hnum,
saddr, htons(sport));
#ifdef EXTENSION
// 直接取索引指示的套接字
result = reusesk[hash%MAX];
// 如果只有一组reuseport的套接字，则直接返回，否则回退到原始逻辑
if (num_reuse == 1)
break;
#endif
matches = 1;
}
} else if (score == badness && reuseport) {
matches++;
if (((u64)hash * matches) >> 32 == 0)
result = sk;
hash = next_pseudo_random32(hash);
}
}非常简单的修改。除此之外，每当有套接字被销毁，除了将其数组对应的索引位设置为NULL之外，对其它索引为的元素没有任何影响，后续有新的套接字被创建的时候，只需要找到一个元素为NULL的位置加进去就好了，这就解决了由于套接字位置变动造成数据包被定向到错误的套接字问题(因为索引指示的位置元素已经由于移动位置而变化了)。这个问题的影响有时是剧烈的，比如后续所有的套接字全部向前移动，将影响多个套接字，有时影响又是轻微的，比如用最后一个套接字填补设置为NULL的位置，令人遗憾的是，即使是4.6的内核，其采用的也是上述后一种方式，即末尾填充法，虽然只是移动一个套接字，但问题依然存在。幸运的是，4.6内核的reuseport支持BPF，这意味着你可以在用户态自己写代码去控制套接字的选择，并可以实时注入到内核的reuseport选择逻辑中。首先，我们可以将一个reuseport套接字组中所有的套接字按照其对应的PID以及内存地址之类的唯一标识，HASH到以下16bits的线性空间中(其中第一个套接字占据端点位置)，如下图所示：
这样N个socket就将该线性空间分割成了N个区间，我们把这个HASH的过程称为第一类HASH！接下来，当一个数据包到达时，如何将其对应到某一个套接字呢？此时要进行第二类hash运算，这个运算的对象是数据包携带的源IP/源端口对，HASH的结果对应到前述16bits的线性空间中，如下图所示：
标签：
原文地址：http://blog.csdn.net/dog250/article/details/51510823
