DPDK背景和优势

1.传统的收发报文方式都必须采用硬中断来做通讯，每次硬中断大约消耗100微秒，这还不算因为终止上下文所带来的Cache Miss。

2.数据必须从内核态用户态之间切换拷贝带来大量CPU消耗，全局锁竞争。

3.收发包都有系统调用的开销。

4.内核工作在多核上，为可全局一致，即使采用Lock Free，也避免不了锁总线、内存屏障带来的性能损耗。

5.从网卡到业务进程，经过的路径太长，有些其实未必要的，例如netfilter框架，这些都带来一定的消耗，而且容易Cache Miss

 

1、传统服务器可能有如下潜在的问题

• 异步模式的弊端
  • 在没有请求到来的时候，线程将会休眠，当数据到来时，将由操作系统唤醒对应的线程，也就是说内核需要负责线程间频繁的上下文切换，我们是在依靠操作系统调度系统来服务网络包的调度。
• 协议栈的扩展性
  • 协议栈中嵌入了大量用于对接的接口,如果能让应用程序直接接管网络数据包处理、内存管理以及CPU调度，那么性能可以得到一个质的提升。为了达到这个目标，第一个要解决的问题就是绕过Linux内核协议栈
• 多核的可扩展性
  • 在多个CPU核心上平行扩展：尽量让每个核维护独立数据结构；使用原子操作来避免冲突；使用无锁数据结构避免线程间相互等待；设置CPU亲缘性，将操作系统和应用进程绑定到特定的内核上，避免CPU资源竞争；在NUMA架构下尽量避免远端内存访问
• 内存的可扩展性
  • 内存的访问速度永远也赶不上cache和cpu的频率，为了能让性能平行扩展，最好是少访问。

减少访存次数来避免cachemisses是我们设计的目标。

指针不要随意指向任意内存地址，因为这样每一次指针的间接访问可能会导致多次cache misses，最好将需要访问的数据放到一起，方便一次性加载到cache中使用。按照4K页来计算，32G的数据需要占用64M的页表，使得页表甚至无法放到cache中，这样每次数据访问可能需要两次访问到内存，因此建议使用2M甚至1G的大页表来解决这个问题。

1. 解决方案

• 控制层留给Linux做，其它数据层全部由应用程序来处理。
  减少系统调度、系统调用、系统中断，上下文切换等
• 摒弃Linux内核协议栈，将数据包传输到用户空间定制协议栈
• 使用多核编程技术替代多线程，将OS绑在指定核上运行
• 针对SMP系统，使CPU尽量使用所在NUMA系统节点的内存，减少内存刷写
• 使用大页面，减少访问
• 采用无锁技术解竞争

 

概念：

DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包，绕过了Linux内核协议栈对数据包处理过程。Linux内核将DPDK应用程序看作是一个普通的用户态进程，包括它的编译、连接和加载方式和普通程序没有什么两样。

传统linux网络层:

硬件中断--->取包分发至内核线程--->软件中断--->内核线程在协议栈中处理包--->处理完毕通知用户层

用户层收包-->网络层--->逻辑层--->业务层

dpdk网络层:

硬件中断--->放弃中断流程
用户层通过设备映射取包--->进入用户层协议栈--->逻辑层--->业务层 

linux协议栈：

https://www.cnblogs.com/sammyliu/p/5225623.html

https://cloud.tencent.com/developer/article/1198333

dpdk优势:

• 减少了中断次数。
• 减少了内存拷贝次数。
• 绕过了linux的协议栈，进入用户协议栈，用户获得了协议栈的控制权，能够定制化协议栈降低复杂度

 

dpdk劣势

• 内核栈转移至用户层增加了开发成本.
• 低负荷服务器不实用，会造成内核空转