linux内核IMQ源码实现分析

本文档的Copyleft归wwwlkk所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性，严禁用于任何商业用途。

E-mail: wwwlkk@

来源: /?business&aid=6&un=wwwlkk#7

linux2.6.35内核IMQ源码实现分析

（1）数据包截留并重新注入协议栈技术 (1)

（2）及时处理数据包技术 (2)

（3）IMQ设备数据包重新注入协议栈流程 (4)

（4）IMQ截留数据包流程 (4)

（5）IMQ在软中断中及时将数据包重新注入协议栈 (7)

（6）结束语 (9)

前言：IMQ用于入口流量整形和全局的流量控制，IMQ的配置是很简单的，但很少人分析过IMQ的内核实现，网络上也没有IMQ的源码分析文档，为了搞清楚IMQ的性能，稳定性，以及借鉴IMQ的技术，本文分析了IMQ的内核实现机制。

首先揭示IMQ的核心技术：

1.如何从协议栈中截留数据包，并能把数据包重新注入协议栈。

2.如何做到及时的将数据包重新注入协议栈。

实际上linux的标准内核已经解决了以上2个技术难点，第1个技术可以在NF_QUEUE机制中看到，第二个技术可以在发包软中断中看到。下面先介绍这2个技术。

（1）数据包截留并重新注入协议栈技术

（2）及时处理数据包技术

QoS有个技术难点：将数据包入队，然后发送队列中合适的数据包，那么如何做到队列中的数

激活状态的队列是否能保证队列中的数据包被及时的发送吗？接下来看一下，激活状态的队列的

证了数据包会被及时的发送。

这是linux内核发送软中断的机制，IMQ就是利用了这个机制，不同点在于：正常的发送队列是将数据包发送给网卡驱动，而IMQ队列是将数据包发送给okfn函数。

以上2个技术点就是IMQ的关键技术，下面是IMQ的具体流程。（3）IMQ设备数据包重新注入协议栈流程

（4）IMQ截留数据包流程

（5）IMQ在软中断中及时将数据包重新注入协议栈

到这里IMQ整个流程已经分析结束。

（6）结束语

使用SmartFlow对IMQ做了测试，发现IMQ有些不稳定：

1）在低压力下会丢失几个数据包。

2）总体的性能降低很大。

所以IMQ并是不一个理想的QoS方案，所以这里对IMQ就不做更详细的分析。