linux tcp中的几个队列

    Tcp的处理中使用了三个队列，receive_queue，backlog_queue，pre_queue，在数据包到达tcp协议栈时，持有sk自旋锁，
然后检查当前使用有进程上下文操作sk的逻辑，通过sock_owned_by_user判断，如果sk_lock.owned被赋值说明进程持有sk，
如果为0则可以在当前软中断上下文中，继续数据报文的处理。

    当sk_lock.owned赋值时，skb通过sk_add_backlog被放在了sk_backlog队列的尾部，等待进程release_sock时处理，在
release_sock时，会将sk_backlog临时保存（私有化，与sock脱离），然后逐一进行skb的处理。这个过程是调用sk_backlog_rcv
实现的，实际上是tcp_v4_do_rcv函数。这里的函数使用是在进程上下文中（关了bh），每处理结束一个skb后，都会检查是
否需要调度，如果需要调度，则打开bh，调度，等到重新执行时关闭bh，因此整个过程中可能会产生睡眠。

    当sk_lock.owned没有赋值时，说明当前没有进程/用户在操作sk，会首先调用tcp_prequeue尝试将数据报文加入pre_queue，
如果无法加入pre_queue时，则走普通流程在软中断上下文中调用tcp_v4_do_rcv进行后续处理，后续动作与进程/用户在
release_sock中执行的sk_backlog_rcv（tcp_v4_do_rcv）相同。

    tcp_prequeue函数负责向pre_queue中添加skb，无法添加的原因只有两个：
    一是用户为了降低延迟，全局关闭了pre_queue的功能（通过sysctl_tcp_low_latency开关）
    二是当前没有进程/用户等待处理该sk上的报文，即tp->ucopy.task为0时，也不能使用pre_queue。
    
    下面这篇文章对prequeue做出了评价，可以参考一下，，其中对一些概念的澄清，摘录如下
    tcp中分为快速路径（fast path）和慢速路径(slow path)，让我想到了网络设备的control path和data path（其实不挨着），
所谓fast path不是指pre_queue path，slow path也不是指处理backlog_queue和receive_queue的path。fast path需要一些附加条件，
其含义是复制到用户空间或者按序进入receive_queue的处理路径，slow path指的是乱序报文的处理以及其他不符合fast path的数据
包的处理方式。这些path与数据报文进入那个队列没有关系，一般是将fast path分为两类：
    直接复制进用户空间的路径是most-fast-path，没有进程上下文导致按序的skb进入receive_queue的是more-fast-path。
    由于处理乱序包或缓冲区用尽这些情况很麻烦，因此处理这些情况的path就是slow-path，具体是什么path是根据tcp语义和数据包
特性来确定的，和具体协议栈的实现没有关系。