linux源码解读（三十二）：dpdk原理概述（一）

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，