优先权队列规定

优先权队列规定（PRIO queuing discipline） -by maoyk

---

对于PRIO qdisc，Chuck也是同样用了一段话和一个图来解释它：
Priority queuing (PQ) is the basis for a class of queue scheduling algorithms that are designed to provide a relatively simple method of supporting differentiated service classes. In classic PQ, packets are first classified by the system and then placed into different priority queues. Packets are scheduled from the head of a given queue only if all queues of higher priority are empty. Within each of the priority queues, packets are scheduled in FIFO order.

在linux中，PRIO稍有一点复杂。从man手册和Lartc中，会得到解释。PRIO qdisc是一个可以包含任意数目的具有不同优先权的类（class）的分类队列规定（classful queuing discipline）。何时包进入子队列（sub-qdisc）基于通过tc设置的过滤器（filter）命令。当你创建一个新的PRIO队列时，就有三个pfifo子对列规定同时被建好了。事实上，这三个子类默认的标识是m:1,m:2和m:3，m是qdisc的大数部分。这三个子类是采用pfifo作为它自己的qdisc的。

对于这样一个qdisc，当一个数据包需要出队时，：1类中的包首先被处理。：1空的时候处理：2，最后才是：3类。这样的队列显然是会出现问题的。假如你要实现一个DS-AF结构，你决定分别关联DS类AF11，AF21和AF31到PRIO qdisc中提供的这三个class上。当由于出口链路出现冲突而导致出队速率小于包的到达率时，并且同时AF11流的到达率高于离开速率时，此时AF11的包会永远在类：1队列中等待，而类：2和：3中的包根本就不会被处理。
   此时，AF21和AF31的包就不干了。这个问题可以通过改变：1类的pfifo disc为其他类型的qdisc来为AF11流设置一个上限，比如TBF qdisc就可以限定该流的速度。
    这样你可以得出这样的结论，通过仔细的设计，这个PRIO队列能够在实现需要为一些特定的流量提供优先权时派上用场。下面我们看看如何通过tc来进行配置。在这之前，先看看LARTC中关于PRIO的参数的解释。
    tc理解下列的参数：
    bands   需要创建的频段（band）的数目。每一个band实际上是一个class（类），如果你改变这个数目，同时你应该也修改priomap
    priomap 若你没有告诉过滤器（filter）如何来给流量分类，那么PRIO qdisc就将使用TC_PRIO这个属性来决定每一个包如何出队。内核给每一个包分配一个TC_PRIO属性或者叫标识，而这个标记是根据包中的TOS字段或者应用程序传递来的socket选项。
     TC_PRIO是根据TOS字段来标记的，安如下规则来映射：

  

    这三个bands都是class（类），分别叫做major：1到major：3，所以，如果PRIO qdisc叫做12：，那么tc在流量控制时会给12：1（band 0）更高的优先权。band 0对应小数1，band1对应小数2，band3对应小数2.
    priomap参数告诉我们要使用PRIO qdisc，我们需要提供过滤器（filter）因为默认的行为可能不能满足我们的需要。下面我们来示范使用过滤器来建立一个PRIO qdisc。

   

    这次，我们自己命名这个PRIO qdisc为1：0（0可以省略不写）。PRIO会自动地立即创建三个class 1：1，1：2，和1：3，这三个class自己的pfifo队列也同时创建好了。
    下面看看如何来实现过滤器（filter）。我们还是分别分配AF11，AF21和AF31给1：1，1：2和1：3.
    而：AF11=1-2=001010， AF21=2-2=010010，AF31=3-2=011010.这是6bit的DSCP，8bit的TOS就是在这之后再加上2bit的0，这样：AF11=00101000=0x28，AF21=01001000=0x48，AF31=01101000=0x68，最后这8bit的16进制数就是我们需要使用的：

  

    tc filter add dev eth0就是让tc在eth0这个设备上添加一个过滤器。'parent 1:0'意即这个过滤器的parent（父节点）是标识为1：0的对象，即PRIO qdisc。 'prio 1'即将此过滤器设为优选权1；'protocol ip'说明这个过滤器的对象是IP协议。'u32'即这个filter是一个u32过滤器。'match ip'流入的包需要满足IP包头匹配，'tos 0x28 0xff'是说匹配是tos字段为0x28.tc总是将第一个值乘以第二项来得到需要的匹配俄：0x28*0xff还是0x28。比如，使用0xf0，可以来改变匹配值。最终'flowid 1:1'是说匹配这个条件的流将直接被送到标识为1：1的class，而这个就是我们的PRIO 1：1类。
    同理，我们依次配置后两个filter：

  

    这样，我们就建好了如上图所示的这样一个prio qdisc。
    PRIO qdisc也是有它的优缺点的，Chuck这样写道：
   PQ offers a couple of benefits:

• For software­based routers, PQ places a relatively low computational load on the system when compared with more elaborate queuing disciplines.
  
• PQ allows routers to organize buffered packets, and then service one class of traffic differently from other classes of traffic. For example, you can set priorities so that real­time applications, such as interactive voice and video, get priority over applications that do not operate in real time.

   But PQ also results in several limitations:

• If the amount of high­priority traffic is not policed or conditioned at the edges of the network, lower­priority traffic may experience excessive delay as it waits for unbounded higher­priority traffic to be serviced.
  
• If the volume of higher­priority traffic becomes excessive, lower­priority traffic can be dropped as the buffer space allocated to low­priority queues starts to overflow. If this occurs, it is possible that the combination of packet dropping, increased latency, and packet retransmission by host systems can ultimately lead to complete resource starvation for lower­priority traffic. Strict PQ can create a network environment where a reduction in the quality of service delivered to the highest­priority service is delayed until the entire network is devoted to processing only the highest­priority service class.
• A misbehaving high­priority flow can add significantly to the amount of delay and jitter experienced by other high­priority flows sharing the same queue.
• PQ is not a solution to overcome the limitation of FIFO queuing where UDP flows are favored over TCP flows during periods of congestion. If you attempt to use PQ to place TCP flows into a higher­priority queue than UDP flows, TCP window management and flow control mechanisms will attempt to consume all of the available bandwidth on the output port, thus starving your lower­priority UDP flows.