dpdk学习1.1 -- 基础知识储备

以 Linux 为例，传统网络设备驱动包处理的动作可以概括如下： 

�� 数据包到达网卡设备。 

�� 网卡设备依据配置进行 DMA 操作。 

�� 网卡发送中断，唤醒处理器。 

�� 驱动软件填充读写缓冲区数据结构。

 �� 数据报文达到内核协议栈，进行高层处理。 

�� 如果最终应用在用户态，数据从内核搬移到用户态。 

�� 如果最终应用在内核态，在内核继续进行。

随着网络接口带宽从千兆向万兆迈进，原先每个报文就会触发一个中断，中断带来的开 销变得突出，大量数据到来会触发频繁的中断开销，导致系统无法承受，因此有人在Linux 内核中引入了NAPI 机制，其策略是系统被中断唤醒后，尽量使用轮询的方式一次处理多 个数据包，直到网络再次空闲重新转入中断等待。NAPI 策略用于高吞吐的场景，效率提升明显。

无线4G/LTE 数据面网络协议展示了从基站、基站控制器到无 线核心网关的协议层次，可以看到大量处理是在网络二、三、四层进行的。如何让Linux 这 样的面向控制面原生设计的操作系统在包处理上减少不必要的开销一直是一大热点。有个著 名的高性能网络I/O 框架Netmap，它就是采用共享数据包池的方式，减少内核到用户空间的包复制。

---

NAPI 与 Netmap 两方面的努力其实已经明显改善了传统Linux 系统上的包处理能力，那 是否还有空间去做得更好呢？作为分时操作系统，Linux 要将CPU 的执行时间合理地调度 给需要运行的任务。相对于公平分时，不可避免的就是适时调度。早些年CPU 核数比较少， 为了每个任务都得到响应处理，进行充分分时，用效率换响应，是一个理想的策略。现今CPU 核数越来越多，性能越来越强，为了追求极端的高性能高效率，分时就不一定总是上佳 的策略。以Netmap 为例，即便其减少了内核到用户空间的内存复制，但内核驱动的收发包 处理和用户态线程依旧由操作系统调度执行，除去任务切换本身的开销，由切换导致的后续 cache 替换（不同任务内存热点不同），对性能也会产生负面的影响。 如果再往实时性方面考虑，传统上，事件从中断发生到应用感知，也是要经过长长的软件处理路径。