1、操作系统、计算机网络诞生已经几十年了，部分功能不再能满足现在的业务需求。如果对操作系统做更改，成本非常高，所以部分问题是在应用层想办法解决的，比如前面介绍的协程、quic等，都是在应用层重新开发的框架，简单回顾如下：

• 协程：server多线程通信时，如果每连接一个客户端就要生成一个线程去处理，对server硬件资源消耗极大！为了解决多线程以及互相切换带来的性能损耗，应用层发明了协程框架：单线程人为控制跳转到不同的代码块执行，避免了cpu浪费、线程锁/切换等一系列耗时的问题！
• quic协议：tcp协议已经深度嵌入了操作系统，更改起来难度很大，所以同样也是在应用层基于udp协议实现了tls、拥塞控制等，彻底让协议和操作系统松耦合！

　　 除了上述问题，操作还有另一个比较严重的问题：基于os内核的网络数据IO！传统做网络开发时，接收和发送数据用的是操作系统提供的receive和send函数，用户配置一下网络参数、传入应用层的数据即可！操作系统由于集成了协议栈，会在用户传输的应用层数据前面加上协议不同层级的包头，然后通过网卡发送数据；接收到的数据处理方式类似，按照协议类型一层一层拨开，直到获取到应用层的数据！整个流程大致如下：

　 网卡接受数据----->发出硬件中断通知cpu来取数据----->os把数据复制到内存并启动内核线程
　　　　　　　　  --->软件中断--->内核线程在协议栈中处理包--->处理完毕通知用户层

　　大家有没有觉得这个链条忒长啊？这么长的处理流程带来的问题：

• “中间商”多，整个流程耗时；数据进入下一个环节时容易cache miss
• 同一份数据在内存不同的地方存储（缓存内存、内核内存、用户空间的内存），浪费内存
• 网卡通过中断通知cpu，每次硬中断大约消耗100微秒，这还不算因为终止上下文所带来的Cache Miss（L1、L2、TLB等cpu的cache可能都会更新）
• 用户到内核态的上下文切换耗时
• 数据在内核态用户态之间切换拷贝带来大量CPU消耗，全局锁竞争
• 内核工作在多核上，为保障全局一致，即使采用Lock Free，也避免不了锁总线、内存屏障带来的性能损耗

 　   这一系列的问题都是内核处理网卡接收到的数据导致的。大胆一点想象：如果不让内核处理网卡数据了？能不能避免上述各个环节的损耗了？能不能让3环的应用直接控制网卡收发数据了？

       2、如果真的通过3环应用层直接读写网卡，面临的问题：

•    用户空间的内存要映射到网卡，才能直接读写网卡
•    驱动要运行在用户空间

     （1）这两个问题是怎么解决的了？这一切都得益于linux提供的UIO机制！ UIO 能够拦截中断，并重设中断回调行为（相当于hook了，这个功能还是要在内核实现的，因为硬件中断只能在内核处理），从而绕过内核协议栈后续的处理流程。这里借用别人的一张图：

 　　UIO 设备的实现机制其实是对用户空间暴露文件接口，比如当注册一个 UIO 设备 uioX，就会出现文件 /dev/uioX（用于读取中断，底层还是要在内核处理，因为硬件中断只能发生在内核），对该文件的读写就是对设备内存的读写（通过mmap实现）。除此之外，对设备的控制还可以通过 /sys/class/uio 下的各个文件的读写来完成。所以UIO的本质：

• 　让用户空间的程序拦截内核的中断，更改中断的handler处理函数，让用户空间的程序第一时间拿到刚从网卡接收到的“一手、热乎”数据，减少内核的数据处理流程！由于应用程序拿到的是网络链路层（也就是第二层）的数据，这就需要应用程序自己按照协议解析数据了！说个额外的：这个功能可以用来抓包！

　 简化后的示意图如下：原本网卡是由操作系统内核接管的，现在直接由3环的dpdk应用控制了！

　  这就是dpdk的第一个优点；除了这个，还有以下几个：

   （2）Huge Page 大页：传统页面大小是4Kb，如果进程要使用64G内存，则64G/4KB=16000000（一千六百万）页，所有在页表项中占用16000000 * 4B=62MB；但是TLB缓存的空间是有限的，不可能存储这么多页面的地址映射关系，所以可能导致TLB miss；如果改成2MB的huge Page，所需页面减少到64G/2MB=2000个。在TLB容量有限的情况下尽可能地多在TLB存放地址映射，极大减少了TLB miss！

   （3）mempool 内存池：任何网络协议都要处理报文，这些报文肯定是存放在内存的！申请和释放内存就需要调用malloc和free函数了！这两个是系统调用，涉及到上下文切换；同时还要用buddy或slab算法查找空闲内存块，效率较低！dpdk 在用户空间实现了一套精巧的内存池技术，内核空间和用户空间的内存交互不进行拷贝，只做控制权转移。当收发数据包时，就减少了内存拷贝的开销！

　（4）Ring 无锁环：多线程/多进程之间互斥，传统的方式就是上锁！但是dpdk基于 Linux 内核的无锁环形缓冲 kfifo 实现了自己的一套无锁机制，支持多消费者或单消费者出队、多生产者或单生产者入队；

   （5）PMD poll-mode网卡驱动：网络IO监听有两种方式，分别是

• 事件驱动，比如epoll：这种方式进程让出cpu后等数据；一旦有了数据，操作系统负责唤醒进程继续执行！这种方式适合于接收的数据量不大，但实时性要求高的场景；
• 轮询，比如poll：本质就是用死循环不停的检查内存有没有数据到来！这种方式适合于接收大块数据，实时性要求不高的场景；

　　dpdk采用第二种轮询方式：直接用死循环不停的地检查网卡内存，带来了零拷贝、无系统调用的好处，同时避免了网卡硬件中断带来的上下文切换、cache miss、硬中断执行等损耗！

     （6）NUMA：dpdk 内存分配上通过 proc 提供的内存信息，使 CPU 核心尽量使用靠近其所在节点的内存，避免了跨 NUMA 节点远程访问内存的性能问题；其软件架构去中心化，尽量避免全局共享，带来全局竞争，失去横向扩展的能力

　 （7）CPU 亲和性： dpdk 利用 CPU 的亲和性将一个线程或多个线程绑定到一个或多个 CPU 上，这样在线程执行过程中，就不会被随意调度，一方面减少了线程间的频繁切换带来的开销，另一方面避免了 CPU L1、L2、TLB等缓存的局部失效性，增加了 CPU cache的命中率。

参考：

1、https://cloud.tencent.com/developer/article/1198333  一文看懂dpdk