DPDK QOS1 -- 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框架的调度体系如下图：
DPDK QOS1 -- Linux HQOS的框架相关推荐
- Linux PCI驱动框架分析：（Peripheral Component Interconnect，外部设备互联）
<DPDK 20.05 | rte_pci_bus思维导图 | 第一版> <linux系统下:IO端口,内存,PCI总线 的 读写(I/O)操作> <Linux指令:ls ...
- Linux USB驱动框架分析 【转】
转自:http://blog.chinaunix.net/uid-11848011-id-96188.html 初次接触与OS相关的设备驱动编写,感觉还挺有意思的,为了不至于忘掉看过的东西,笔记跟总结 ...
- Linux uart驱动框架
Linux uart驱动框架 串口驱动框架包括两部分 struct uart_driver int uart_register_driver(struct uart_driver *uart); vo ...
- buildroot：Linux平台构建嵌入式Linux系统的框架
buildroot是Linux平台上一个构建嵌入式Linux系统的框架.整个Buildroot是由Makefile脚本和Kconfig配置文件构成的.你可以和编译Linux内核一样,通过buildro ...
- platform框架--Linux MISC杂项框架--Linux INPUT子系统框架--串行集成电路总线I2C设备驱动框架--串行外设接口SPI 设备驱动框架---通用异步收发器UART驱动框架
platform框架 input. pinctrl. gpio 子系统都是 Linux 内核针对某一类设备而创建的框架, input子系统是管理输入的子系统 pinctrl 子系统重点是设置 PIN( ...
- Linux SPI驱动框架(2)——控制器驱动层
SPI控制器驱动层 上节中,讲了SPI核心层的东西,这一部分,以全志平台SPI控制器驱动为例,对SPI控制器驱动进行说明. SPI控制器驱动,即SPI硬件控制器对应的驱动,核心部分需要实现硬件SP ...
- Linux I2C驱动框架（超详细）
Linux I2C驱动框架 文章目录 Linux I2C驱动框架 一.几个重要的对象 1.I2C总线 2.I2C驱动 3.I2C设备 4.I2C设配器 小结 二.内核源码分析 1.注册I2C驱动 2. ...
- Linux平台设备框架驱动
Linux平台设备框架驱动 平台设备框架(platform)是将一个驱动分为设备层和驱动层两个部分,通过总线模型将设备和驱动进行绑定.在系统中每注册一个设备,都会与之匹配一个驱动,同样的,每注册一 ...
- linux使用flask设计网站,linux下Flask框架搭建简单网页
开始安装FLASK需要创建一个虚拟环境,虚拟环境可以不干扰正在使用的系统环境,避免影响,并且也不需要完全的root权限,更加安全可靠. 搭建环境 Python3.4 进入到microblog目录下创建 ...
- Linux下V4L2框架基于SDL库本地USB摄像头监控
Linux下V4L2框架基于SDL库本地USB摄像头监控 1.摄像头框架编程步骤 (1)打开摄像头设备(/dev/video0 ./dev/video1 ) (2)设置图像格式:VIDIOC_S_FM ...
最新文章
- 002.Heartbeat部署及httpd高可用
- tf.keras.losses.KLDivergence KL散度 损失函数 示例
- Java-Reflection反射-获取包括父类在内的所有字段
- svg圆弧进度条demo
- 查询类网站或成站长淘宝客新金矿
- Python3十大经典错误及解决办法
- 【UWP】批量修改图标尺寸
- Android开发笔记（一百七十八）更安全的数据仓库DataStore
- Netty in action—ChannelHandler和ChannelPipeline
- android token加密_Android使用token维持登陆状态的方法
- webstorm主题网址
- Palo Alto Networks 升级Traps高级终端防护产品 提升终端安全防护水平
- js中new操作符到底干了什么？
- 网络推销经典案例——所有的骗子都应该向他学习
- 如何在Mac上查找重复文件？
- 实践数据湖iceberg 第十一课 测试分区表完整流程(造数、建表、合并、删快照)
- 如何通过iPhone或Android手机制作自己的QR码
- java接口与抽象类的异同
- C#命名空间 System.IO思维导图
- hopfileld神经网络_图卷积神经网络