linux内核中协议栈--tcp实现的一点细节

晨曦之光 发布于 2012/04/10 15:00
阅读 728
收藏 0

tcp_recvmsg中的release_sock,如有接收到的包,都必须往backlog链表中添加,在__release_sock之后sk->sk_lock.owner = NULL,表明此时的sock拥有进程上下文,并且还没有人使用,那么此时进入的包可以有机会进入prequeue队列,此时的backlog队列和receive_queue已经清空,此时进入prequeue的设为数据1,然后又锁住sock,至此之后再进来的包将进入backlog,设为数据2,显然数据2比数据1更靠后,因此再函数的最后,首先将更靠前的数据1放入receive_queue,然后在最后release_sock的时候处理backlog的skb。有一个很重要的点,那就是:
if (copied >= target) {
    /* Do not sleep, just process backlog. */
    release_sock(sk);
    lock_sock(sk);
}
如果数据已经拷贝完毕,那么就要将所有未决的skb全部处理完。在tcp_recvmsg,首先遍历receive_queue,一个一个的处理,receive_queue的入队规则保证它里面的skb是正序的,然后如果没有了数据就会睡眠一会,睡之前处理backlog,醒来后会去处理prequeue,因为prequeue中的skb是进程处理完backlog之后,睡眠之前或者之后插入的,如果是之后,那么进程就会被唤醒。总之,正如注释中所说:1. packets in flight;2. backlog;3. prequeue;4. receive_queue这四个队列,只有下一个空了才能处理上一个。下面有个完整的描述:
      首先只要有进程lock住了一个socket,那么新接收的skb必须放到backlog队列中,如果在进程recvmsg的中途因为某种原因用户进程释放了socket,但是还是保持了ucopy结构体的话,那么此时新接收的skb将有机会进入prequeue,在理解起来更简单的情况下,我们可以忽略prequeue,因此这个队列仅仅是一个可选的优化。为了从最简单起步,我们暂且不考虑prequeue,也就是说从底层接收的skb要么进入receive_queue,要么进入backlog_queue,如上所述,如果一个socket没有在进程上下文中被使用,那么该skb就链接进receive_queue,相反地情况链接进backlog_queue,为了保证用户进程按顺序接收,在tcp_recvmsg中的最后对backlog中的skb进行了处理,处理方式就是将backlog队列中skb一个个取出来然后再一个个放入receive_queue,这样就保证了用户进程能够按照顺序接收skb,这里的前提是receive_queue中的skb是按照其序列号的顺序放入的,在放入receive_queue队列的时候要判断skb的序列号看正确与否,如果不正确的话将把此skb放入一个out_of_order的队列,等到以后裁决,实际上也不是什么以后裁决,在每次插入skb到receive_queue的时候,都会检查这个out_of_order的队列,看一下能否从中抽出一个skb放入到receive_queue,换句话说只要接收到下一个要接收的skb,那么就检查out_of_order队列,尽可能的将out_of_order队列的skb拼接进receive_queue,举一个简单的例子,主机下一个要接收skb的序列号是20,然后主机接收到一个序列号为20的skb,那么很显然将它排入了receive_queue,然后更新下一个要接收的序列号为21,此时主机接收到一个序列号为23的skb,没有按序,因此不更新下一个要接收的序列号,继续等待序列号为21的skb,同时将23号放入out_of_order的队列,接下来接收到一个序列号为22的skb,不更新,继续等待21,同时将22号放入out_of_order的队列,然后21号的skb姗姗来迟,首先将下一个要接收的skb的序列号更新为22,然后察看out_of_order的队列的所有的skb,最终22号和23号都出来了,更新下一个要接收的skb的序列号为24...要指出的是,out_of_order队列中的skb是按照序列号的顺序排列的,并不是乱排的,然而backlog中的skb却不考虑顺序,因为最终它还要经过receive_queue裁决的。
      接下来看看接收过程的fast-path和slow-path,所谓fast指的是尽可能的直接往用户空间复制,这样会减少队列操作,但是这种快速操作的要求是很高的,比如必须是按序的skb才能直接往用户空间拷贝,另外还有很多别的要求,否则就要往receive_queue中链接,可能还要涉及到out_of_order队列,这就是所谓的慢速操作。因此一个skb只有三种结局,一个是加入receive_queue,然后拷至用户空间,一个是加入out_of_order队列,然后再加入receive_queue,最终拷贝到用户空间,还有一种是直接拷贝到用户空间
      现在看一下这个prequeue优化,事实上不要prequeue而直接将skb放入receive_queue也是可以的,但是首先我们可以看一下往receive_queue中添加skb的繁琐度,主要在函数tcp_rcv_established中体现,另外我们看一下往prequeue中添加skb的繁琐度,直接入队就返回了,不用进行任何判断,从代码执行效率的角度来看,tcp_v4_rcv是在软中断上下文中执行的,一般不太希望在这种非进程上下文中执行繁琐的操作(软中断也可能执行于进程上下文ksoftirqd),因此使用prequeue比直接往receive_queue放skb要更好一些,在一个就是看看tcp_prequeue中往prequeue中添加skb的条件,那就是socket虽然还有进程上下文,但是该进程已经不再lock该socket了,这种情况发生在进程在tcp_recvmsg中,暂时没有数据可读的时候调用sk_wait_data睡眠了,那么此时如果在软中断上下文中接收了一个skb,那么此skb就会进入到prequeue中,一旦积累了足够多的skb,就会调用:
while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL) {
    sk->sk_backlog_rcv(sk, skb1);
    NET_INC_STATS_BH(LINUX_MIB_TCPPREQUEUEDROPPED);
}
在tcp_rcv_established的处理逻辑中,由于tp->ucopy.task == current这个判断不通过,因此就将此skb尽可能的放入receive_queue中,然后唤醒睡眠的进程,当然也可能放入out_of_order队列中,不过以上的这个所谓的积累足够多是比较不容易发生的,如果总发生,那还不如直接往receive_queue中放呢,事实上在tcp_recvmsg中的lock_sock一直到睡眠,所有进来的skb都没有机会进入prequeue,而是进入了backlock队列中:
if (!sock_owned_by_user(sk)) {
    if (!tcp_prequeue(sk, skb))
        ret = tcp_v4_do_rcv(sk, skb);
} else
    sk_add_backlog(sk, skb);
这些backlog队列中的skb将在进程睡眠前的release_sock中得到处理,如果处理完了之后还是没有完成读取len的任务,那么继续,不过要知道,在处理完全放入receive_queue的backlog队列的skb的时候,还是会有skb进来然后进入backlog的,如果没有任何skb进来,偏偏在sk_wait_data中的release和lock之间有skb进来的话,那么它就会调用tcp_prequeue进入prequeue,然后看看tcp_prequeue中的判断:
else if (skb_queue_len(&tp->ucopy.prequeue) == 1)
    wake_up_interruptible(sk->sk_sleep);
这就是说,只要第一个skb到达prequeue上,那么就会唤醒socket所属于的进程,这样的话,在tcp_recvmsg接下来的逻辑中就会处理prequeue:
do_prequeue:
    tcp_prequeue_process(sk);
顺便看一下sk_wait_data->sk_wait_event:
#define sk_wait_event(__sk, __timeo, __condition)        /
({    int rc;                            /
    release_sock(__sk);                    /
    rc = __condition;                    /
    if (!rc) {                        /
        *(__timeo) = schedule_timeout(*(__timeo));    /
        rc = __condition;                /
    }                            /
    lock_sock(__sk);                    /
    rc;                            /
})
如果tcp_prequeue中的wake_up_interruptible在sk_wait_event中的release_sock和schedule_timeout之间发生的话,那么进程就唤不醒了,但是这种概率非常小,也就是说必须等到__timeo时间之后才会退出睡眠状态从而继续往下走,在这段冤枉的时间里面,可能网络传来的skb非常之多,这些skb瞬间填满了整个ucopy.prequeue的空间,然后就导致了上面那个while ((skb1 = __skb_dequeue(&tp->ucopy.prequeue)) != NULL)的发生,我觉得这里的实现不是很好,可能会带来一些性能上的问题,也不知道到底这个prequeue是优化选项还是退优化选项,如果说是退优化的话,那么前面已经说了原因了,现在说一下说它是优化的原因,既然receive_queue中没有skb了,那么接下来收到的skb很有可能就是需要接收的,注意由于可能有乱序的skb进来,这里仅仅说是可能,于是进一步在处理prequeue的时候,也就是调用tcp_prequeue_process的时候,进而调用tcp_rcv_established的时候,由于此时是在socket所有者进程的上下文,既然可能是正序的skb,那么也就很有可能可以直接将skb复制到用户空间并且成功,这样的话当进程从tcp_recvmsg中的tcp_prequeue_process返回的时候,数据已经进入用户空间了,而不用再重新来一次循环从receive_queue中拉取skb了:
...
if (copied >= target) { //处理未决的skb,所谓未决就是skb不在receive_queue中而是因为receive_queue暂时被使用而不得不加入到了别的队列中,比如backlog队列,这里处理它主要是因为用户进程必须按序接收数据,而一次tcp_recvmsg的调用前后都必须保证所有的还没有读取的skb是顺序存在于receive_queue的,注意并不在这里处理prequeue,也并不认为prequeue中的skb是未决的,它只是receive_queue的暂存地罢了,顺便看看能否偷个懒将skb直接送给用户进程。
    release_sock(sk);
    lock_sock(sk);
} else
    sk_wait_data(sk, &timeo);
if (user_recv) {
    int chunk;
    if ((chunk = len - tp->ucopy.len) != 0) { //在sk_wait_data中的release中可能已经将backlog中的数据直接拷贝到用户空间了,并且更新了ucopy的各个相关字段,tp->ucopy.len在进程上下文调用的sk_backlog_rcv也就是tcp_rcv_established->tcp_copy_to_iovec中被更新,因此在这里能发现这件事
        NET_ADD_STATS_USER(LINUX_MIB_TCPDIRECTCOPYFROMBACKLOG, chunk);
        len -= chunk;
        copied += chunk;
    }
    if (tp->rcv_nxt == tp->copied_seq &&
    skb_queue_len(&tp->ucopy.prequeue)) {
do_prequeue:
        tcp_prequeue_process(sk);
        if ((chunk = len - tp->ucopy.len) != 0) { //和backlog相同的方式发现数据在prequeue中已经拷贝到用户空间了
            NET_ADD_STATS_USER(LINUX_MIB_TCPDIRECTCOPYFROMPREQUEUE, chunk);
            len -= chunk;
            copied += chunk;
        }
    }
...
receive_queue是最重要的队列,backlog是一个临时队列,也很重要,这是因为软中断不能睡眠,也尽量不要长时间争抢锁,如果用户在从内核复制一个很大的数据,那么软中断的tcp_v4_recv就要浪费大量时间等待进程释放sk_lock.owner了,而prequeue是一个可有可无的队列,并且它的存在喜忧参半,无所谓有也无所谓无


原文链接:http://blog.csdn.net/dog250/article/details/5459862
加载中
返回顶部
顶部