DPDK 学习3 -- Linux HQOS的框架

QOS具体的原理这里不展开，QOS包含流量分类、流量标记、流量监管、流量整形、拥塞管理、拥塞避免等技术，上面各种QOS技术在设备上处理的顺序如下：

HQOS与传统的一层QOS相比，最大的区别是可以将调度队列划分为如物理级别、逻辑级别、应用或业务级别等多个调度级别，每一级别可以使用不同的特征进行流量管理，为了理解HQOS我们先了解下递归控制的概念，所谓的递归控制就是分层次地控制，而对于每个层次，控制方式可以一致，也可以不一致。

 

熟悉linux内核调度的都知道，对于组调度和TASK调度都采用了完全相同的调度方式，然而显然组和TASK是属于不同层次的，如下图所示：

从上面可以看出，递归控制是分层的，对于上面的图而言，除了叶子节点之外的每一个节点都是一颗独立的小树，不管是大树还是小树，对于控制或者组织逻辑而言，其性质是完全一样的。

linux实现的QOS框架，对队列进行了抽象（QDISC (排队规则)是queueing discipline的简写），其最主要有两个回调函数指针，一个是enqueue入队操作，一个是dequeue出队操作。不管是enqueue还是dequeue，其都并不一定真正将数据包排入队列，而仅仅是执行规定的一系列的操作，操作包含：
  1、对于叶子节点，入队或者从出队一个数据包；
  2、递归调用其它抽象队列的enqueue/dequeue操作。
 

注意上面提到了其它抽象队列，那么如何来定位这个抽象队列呢？这就需要一个抉择，也就是一个选择器（FILTER），根据数据包的特征来将数据包归入一个抽象队列(类、CLASS)，并可以赋予一定的操作（ACTION），LINUX QOS的框架，如下图的表示：

所以从递归控制的角度和上面的图理解QOS框架，很容易将队列分为真实的队列和抽象的队列，真实队列和抽象队列的地位是平等的，但实际上，它们之间是有层次关系的，正是基于这种递归的“QDISC，CLASS，FILTER”三元组来进行的，让 QOS的框架实现的非常紧凑。

要实现调度，得有一个前提，就是数据包已经在队列里面了，那么目前还有一个问题没有解决，那就是数据包是如何到队列里面的？？

 

对于进程调度而言，进程在被创建或者运行的时候，可以调用setscheduler系统调用来把进程放进某一个调度类的链表或者队列或者红黑树中以便让进程调度模块进行调度，但是对于数据包呢？肯定也有这么一个机制，可以统称为排队的规则（QDISC）。

 

这里的排队规则指的是数据包进入QOS，直到最终排队到某个队列之间的所有的规则，这样理解起来会比那个递归的“QDISC，CLASS，FILTER”更加容易，毕竟除了最终的队列，中间的过程只是决定数据包下一步将走向哪个分支，并不是真正的排队。

 所以说，整个数据包排队就是一系列的决定，最终画出了一条到达最终调度队列的一条唯一的路径，按照图论以及实现效率来理解，确定唯一的一条路径的最好的图就是树（算法导论说的，不太懂），从树根到达某个叶子节点，存在唯一的一条路径。那么，这一系列决定的过程正是数据包向下到达叶子的过程，决策点的唯一问题就在数据包到达数据的枝干节点后如何分支的问题，很显然，这棵树可以是N叉数，每个分支的高度也不一定相同，最终只要能到达一个叶子节点代表的调度队列即可。

 决定数据包走向哪个分支的动作内置在中间节点内部，每一个中间节点的决策算法可以相同也可以不同，这就形成了一个分层递归的结构树，按照这个方法去理解，QOS框架的入队逻辑就会简单多了， 我们可以在每一个中间节点配置一个FILTER， FILTER根据数据包的特征抉择它选择哪个孩子节点，如果在每一个中间节点都放置了一个令牌桶，这样就可以控制进入任意一个分支的数据包的速率。

 

如果说入队操作是在每一个节点按照过滤器配置的策略为一个数据包挑选一个分支最终进入叶子节点真实队列的话，那么出队操作则是一个自根部开始在每一个节点按照调度算法挑选一个分支，一直走到叶子节点取出一个数据包的过程。

 

不管是入队操作还是出队操作都是从根部到叶子的，越接近根部的节点越先参与分类和调度。
 

从出队的过程，我们可以看到这是一个在每一棵子树的每一层按照该子树的根规定的调度算法进行数据包调度的过程，和入队过程一样，这也是一个分层递归的结构树，按照这种理解，QOS的调度实体就是树中的每一个节点，当然也包括叶子节点，对于叶子节点，调度实体可以在任何数据结构中而不必非要是树节点(因为它不会有任何子树了)，调度算法来抉择选择下面一层的哪个调度实体。

我们整个QOS框架的调度体系如下图：