中国工信出版传媒集团副总经理刘华鲁表示，截至2021年底，我国企业上云、使用云的比例达到80%，上云已经成为数字化的必经之路。

以上云为主要特征的数字时代，最典型的一个特征是数据的高速增长。据中国信通院数据，截止2021年底，我国在用数据中心机架规模高达520万架，近5年年均复合增速超过30%，其中大型以上数据中心机架规模420万架，占比达到80%。IDC更是预测，到2025年，数据中心流量预计将增长超过180ZB，数据中心业务高吞吐的发展趋势非常明显。

在数据大爆发的大背景下，数据中心网络内部交换系统也在大提速，从10GE、40GE向100GE、400GE提速，相应的，一场围绕网络数据传输优化的攻坚战也在上演。

云时代的数据传输痛点

云时代，网络传输（I/O）的变革是深刻的。

在传统网络时代，路由器、交换机等设备都是采用硬件的解决方案，基于专用化、定制化的处理器。这种方式的缺点很明显，存在调试维护难、升级迭代难等问题。而且，传统通信专有化设备需要维护多个平台硬件，控制平面、数据平面的软硬件各不相同，维护成本高昂。

尤其是当云时代到来时，通过网络功能虚拟化共享硬件成为行业标配，即通过标准的服务器、标准的以太网交换机来实现各种功能。如英特尔公司早在10多年前就提出4合1战略，即应用、控制、数据、信号处理都统一在IA（Intel Architecture）处理器平台上。

然而，云时代数据的大爆发，为网络数据传输带来极大挑战。在业界，曾经相继出现过C10K、C100K、C10M等难题就是这样。所谓C10K，是单机1万个并发连接问题，同样，C100K是实现单机并发连接100万，C10M是实现千万并发连接。

在硬件上这些问题解决起来不难，堆硬件就可以实现，但是这样做的弊端也显而易见，既成本高昂，又不通用。2013年，Errata Security公司CEO Robert Graham用软件的方式解决了这一难题，他认为，Linux系统的设计初衷是传统电话网络的控制系统，而非服务器OS，不适合处理大规模的网络数据包。

更重要的是，他得出一个结论：OS的内核不是解决C10M问题的路径，相反，OS内核正是导致C10M问题的瓶颈。

数据可以很直观地解释这个结论。以40G接口为例，如果要达到40G线速，一个2.0主频的CPU需要平均16.8ns / 33个cycles处理一个64字节包长的报文。而在IA平台，基于Linux OS内核态的网卡驱动，单核的转发能力只有2Mpps@64B，远低于网卡的最大吞吐能力。

为什么会这样？在老调“芯”说最新一期视频“DPDK：让数据包极速狂奔”中，很形象地解释了其中的重要原因。网络数据传输就像是收发文件、盖章抄送，要完成这个工作，有两种路径，一种路径是专用处理器，另一种路径是通用处理器，而通用处理器之所以效率低，并不是自己本身原因，而是Linux系统的工作模式：因为传统的网卡驱动运行在操作系统内核态，而绝大多数软件代码运行在用户态，内核态的网卡驱动采用中断模式通知CPU处理数据包，而随着网络流量激增，仅仅响应中断就让CPU疲于应付，而在内核态和用户态之间的切换和数据拷贝等额外开销也会浪费CPU的处理能力。

所以，这个时候，急需一套基于常用系统和标准服务器的高性能网络传输开发框架，来规避传统内核态网卡驱动的额外开销，充分利用IA处理器的能力来实现高效的报文转发和处理，更好地应对云时代对数据IO需求的激增。

DPDK技术大揭秘

DPDK技术正是在这种大背景下应运而生。

2008年，DPDK由英特尔公司的网络通信部门提出，主要是针对基于Intel的处理器和网卡开发。正如其全称（Data Plane Development Kit，数据平面开发套件），DPDK提供丰富、完整的框架，让CPU快速实现数据平面应用的数据包处理，高效完成网络转发等工作。

说到这里，有必要解释一下数据平面的概念。在通信框架中，数据传输和连接管理通常被拆分为多个独立的操作，这些操作被称为“平面”，平面包括管理平面、数据平面、控制平面。在传统网络，这些平面都在路由器和交换机的固件中实现，管理平面负责为网络堆栈各个层级和网络系统的其他部分提供管理、监控和配置服务；控制平面决定流量的传输路径；数据平面又称为用户平面，承载用户流量，并负责接口间的数据包转发。

DPDK的主要目的就是通过提供简单、完整的框架，快速实现数据平面应用的数据包处理，其核心特征就是绕过了Linux内核态对数据包的处理过程，直接在用户态收发包来解决内核的瓶颈。用收发文件来类比，传统的方式是从网卡到用户态，需要先通过内核，就像文件不是直接送给你，而是中间要经过传达室一样，这样的效率可想而知。而DPDK绕过内核，避免了从内核态向用户态拷贝数据的开销，以及内核态与用户态切换的开销，就像文件直接送给你一样，能够实现更高的效率。

除了用户态驱动，DPDK用轮询模式解决了中断响应造成的上下文切换开销。借用老调“芯”谈视频的类比，中断模式，就像是每送来一个文件，就拍你一下，让你看有文件来了，而轮询模式则是直接将文件放到你的桌子上，你有空抬头看一眼就拿过来处理。显然，轮询的模式效率更高。

绑定处理核的做法，则让DPDK解决了OS对报文处理核调度的开销问题。传统上，多核处理器在工作时，数据包可能会跨越多个CPU核心，这容易造成CPU缓存失效，DPDK具有CPU亲和性，将线程和CPU核进行一对一绑定，减少了彼此之间的调度切换的开销。同样用收发文件来类比，原来是一份文件在运输过程中由几个人完成，每换一个人都需要交接，而DPDK的绑定处理核的做法则是每一份文件都由专人负责到底，中间省去了交接的开销。

此外，DPDK还用大页内存代替普通内存，减少了缓存失效问题；用无锁技术解决了资源竞争问题等等。可以这样说，DPDK的每一个技术，或者采用的每一种方法都是为了节省数据包的处理时间，让数据加速奔跑。

目前，DPDK已经开源，越来越多的厂商参与进来贡献代码，这使得DPDK可以支持更多的CPU和网卡，如CPU不仅支持IA，还支持AMD、ARM等厂商的处理器，网卡支持的范围也包括Intel网卡、Mellanox网卡、ARM集成网卡等。

据了解，目前DPDK广泛应用在通信、互联网领域，很多的开源项目也利用DPDK作为传输的加速通道，比如OVS。作为优秀的用户空间高性能数据包加速套件，DPDK现在已经作为“胶水”模块被用于多个网络数据处理方案中，用来提升性能。

在招聘网站上，笔者也注意到DPDK相关职位也变得越来越热门，很多云计算厂商都在高薪招聘“DPDK网络开发工程师”等职位。

总而言之，DPDK在云时代影响深远，它解决了通用处理器如何快速处理数据包的问题，也一举粉碎了“IA处理器不适用于数据平面IO高速转发业务场景”的传统观点，让通用处理器代替专用处理器，高效地支撑起数字时代的数据洪流。