打破 DPDK 的误区： 数据面最流行的工具包 DPDK，前世今生，未来

简介

数据平面开发套件（DPDK）软件是一组用户空间库和驱动程序，可加速在所有主要 CPU 架构上运行的数据包处理工作负载。 由 Intel 大约 10 年前创建，现在是 Linux 基金会旗下的开源项目之一。从企业数据中心到公共云的环境，尤其是在电信网络中， DPDK 在推动高性能通用 CPU 的使用方面都起了重大作用。

更多 DPDK 资料：

【冲破内核瓶颈，让I/O性能飙升】DPDK工程师手册

DPDK 是什么

DPDK 是 Linux 基金会托管的一个开源项目。 为了加快网络 I / O，DPDK 允许传入网络数据包过渡到用户空间，进而消除了内存复制的开销，在不进行内存复制的情况下，这些数据包将被快速处理用户空间和内核空间之间上下文切换的开销。DPDK 扩展了标准内核网络堆栈，在高吞吐量和/或 低延迟至关重要，例如无线核心，无线访问，有线基础设施，路由器，负载均衡器，防火墙，视频流，IP 语音等。 许多流行的 Linux 发行版，包括由 Red Hat 和 Canonical 支持的发行版将 DPDK 支持作为其标准包装的一部分。

为什么需要 DPDK-DPDK 的发展史

传统上，由思科，爱立信，华为，瞻博网络， 中兴和诺基亚等供应商提供的联网设备使用 ASIC 来执行低级数据平面功能，例如数据包处理。在某些情况下，这些 ASIC 是专有的，而在其他产品则是诸如 Broadcom 或 Marvell 之类的芯片供应商提供的标准产品。反过来，利用了 ASIC 通过专有软件来实现防火墙，路由器，交换机，基站支持的各种网络协议站和其他网络设备。这些架构提供了高性能所需的吞吐量网络方面，新产品推出的时间表受到漫长的芯片开发/调试周期以及供应商之间没有软件可移植性的机会。到 2007 年，半导体公司如 Intel，Cavium（现在是 Marvell 的一部分），Freescale（现在是 NXP 的一部分）和 NetLogic（现在 Broadcom 的一部分）正在引入具有足够处理能力的标准多核处理器，以执行低级数据包处理功能需要以与基于 ASIC 的网络有效竞争所需的成本和性能产品。问题出在软件上：Linux 是网络设备的默认操作系统，而 Linux 内核包含许多瓶颈，无法有效处理数据包。需要一种在保持与 Linux 兼容性的同时消除这些性能限制的解决方案应用程序。它适合作为 Linux 发行版中存在的库进行打包，以供在需要时使用。管理各种网络设备。

这些目标最初是在 2010 年实现的，当时英特尔推出了针对 Xeon 一代的 DPDK 初始版本基于 Nehalem 微体系结构的处理器。 DPDK 绕过 Linux 内核，在用户中执行数据包处理空间以最大化网络性能。 DPDK 通过使用用户中运行的轮询模式驱动程序（PMD）来实现此目的空间，不断检查传入的数据包队列以查看是否有新数据到达，从而实现了高吞吐量和低吞吐量延迟（下图）。目前，根据开放源 BSD 许可，通过.zip 文件提供了 DPDK

2013 年，网络软件供应商 6WIND 建立了 DPDK.org 开源社区，以开发人员为中心资源，托管库，驱动程序，文档，开发人员的邮件列表和 git 存储库。 DPDK.org 的出现促进了 DPDK 的使用量的增加，以及来自不断扩大的 IPDK 池对 DPDK 的捐款的显着增长全球开发商。

误区 #1: DPDK 是英特尔控制的

在 DPDK 的早期，英特尔确实对该项目产生了巨大的影响。 但是，随着项目的发展社区的多样性也不断发展，例如 Chelsio 和 Mellanox 等设备供应商的贡献以及其他成员的贡献都占了重要比例。 英特尔继续为改进了 DPDK 提供支持，但其他非 x86 体系结构的供应商（例如 Arm，Power 和 Tilera）拥有将 DPDK 推到了纯粹的 x86 外都多种平台。 如前所述，Linux 基金会的治理结构会引导 DPDK 项目容纳更多都参与者，包括英特尔。

DPDK 在 NFV 和其发展中扮演的角色

在电信行业中，随着公司开发解决方案来满足 DPDK 的要求，DPDK 成为关键的使能技术。网络功能虚拟化（NFV）的目标。 NFV 计划始于 2012 年，当时有七个通讯服务提供商（CSP）同意在 ETSI 的主持下进行合作：AT＆T，BT，德国电信，Orange，意大利电信，西班牙电信和 Verizon。成员公司的列表增长迅速，现在包括 800 多个组织，其中包括 CSP，供应商，公共云提供商，研究人员，学术界和政府实体。

NFV 的主要目标是实现网络功能作为标准托管的虚拟化软件的实现服务器平台，而不是传统的网络设备，后者包含在专有软件上运行的专有软件硬件。为了使这种方法具有成本效益，虚拟网络功能（VNF）至关重要。在以下情况下在标准 CPU 架构上运行时，能够获得足够的性能，吞吐量和延迟管理程序的控制。原始的 ETSI NFV 白皮书概述了该计划的目标和高层架构，将 DPDK 与多核处理器和电信级一起确定为 NFV 的关键启用技术虚拟化平台。大部分电信流量由小数据包组成；没有 DPDK，瓶颈与在 Linux 内核中处理这些数据包相关联将阻止 VNF 达到所需的性能水平。但是，通过在 VNF 本身和虚拟交换机（vSwitches）中利用 DPDK，开发人员能够实现高吞吐量和低延迟，从而使 NFV 概念成为可行且具有成本效益的固定功能设备的替代品。

尽管 NFV 的最初前提是在标准服务器上运行虚拟化工作负载，但现在重点是加速平台，包括智能网络接口卡（SmartNIC）和/或图形处理单元（GPU），这样可以大大减少主机 CPU 资源需求，从而节省大量的 CAPEX 和 OPEX。工作是 DPDK 社区中正在进行的工作，以确保 SmartNIC 和 GPU 都可以作为 DPDK 的加速器进行接口，当系统中有 SmartNIC 和 GPU 资源时，使应用程序能够利用它们。

误区 #2 智能网卡会杀死 DPDK

在 SmartNIC 本身上，有一些使用 DPDK 的 SmartNIC 体系结构将数据包移入用户的用户空间。在 NIC 上运行的操作系统。 DPDK 还提供了与 SmartNIC 的接口，从而简化了相互之间的交互。智能网卡。 无论是基于 ASIC，CPU，FPGA 还是 NPU 的 DPDK 都能为 SmartNIC 增加价值。

Linux 基金会和 DPDK

在 2017 年，DPDK 加入 Linux 基金会，一个以为促进开源技术广泛合作的中立家园。现在，DPDK 项目包括一个核心软件项目，DPDK 本身以及各种 与 DPDK 密切相关的较小子项目。 DPDK 的核心项目由许多软件 git 组成存储库，包括主存储库，几个“下一个”存储库，这些存储库用于将更改应用到存储库的特定部分将 DPDK 放入主存储库和稳定发行版存储库之前。 每个项目都有自己的维护者和维护过程。

DPDK 的治理是由两个不同的委员会（管理董事会和技术委员会）推动的。 管理董事会负责预算，市场营销，实验室资源，管理，法律和许可问题。 技术委员会负责技术问题，包括批准新的子项目，弃用旧的子项目以及解决技术纠纷。这两个委员会是对等的，并且一起监督 DPDK 项目。 BSD 下提供了主要的 DPDK 代码许可，而与 Linux 内核相关的部分则根据 GPL 许可。

Linux 基金会在世界各地组织了许多针对 DPDK 的活动。 DPDK 峰会涵盖了最新的 DPDK 框架的开发和相关项目已在中国，欧洲，印度和北美的多个城市举行。 在欧洲则举行了规模较少但技术含金量更高的 DPDK userspace 峰会，并提供了包括路线图在内的更具技术性的议程。

DPDK 社区的发展

到 2019 年末，DPDK 的贡献者来自 25 个以上组织的 160 多位专家。独立于技术贡献者之外，DPDK 项目有两种成员资格。 有 10 个金牌会员：Arm，AT＆T，爱立信，F5，英特尔，Marvell，Mellanox，恩智浦，红帽和中兴通讯。 银牌会员三名：6WIND，华为和博通。（AMD 将成为 DPDK 第四个银牌会员） 金牌会员在董事会中具有更大的代表权。

越来越多的开源项目利用 DPDK。 其中包括 ANS，BESS，Butterfly，DPVS，FD.io / VPP，FastClick，Lagopus，MoonGen，mTCP，OPNFV，OpenDataPlane，Open vSwitch，Packet-journey，Pktgen-dpdk，PcapPlusPlus，Ruru，Seastar，SPDK，TRex，WARP17，YANFF 和 AStack。 作为 Open vSwitch（OvS）的一部分，DPDK 被广泛部署全球云，企业和电信数据中心。

误区 #3 DPDK 是一个封闭且排他的社区

的确，DPDK 项目是由一小组专家和非常熟悉 Linux 内核和设备驱动程序编程的 Guru 们组成的。 但是，伴随社区显着和持续的增长，已经有数百人参与该项目， 包括硬件开发人员， 软件开发人员， 质量保证人员，文档编写者和最终用户的开发人员。 DPDK 已经超越最初只有少数公司参与，现在有数十家公司参与 DPDK 项目的发展。 任何人都可以通过https://www.dpdk.org/contribute/ 成为 DPDK 的成员。 所有提交均经过项目维护专家审查吸收变更以确保符合质量标准并遵循最佳的实践。

DPDK 市场发展

DPDK 的大多数应用最初是在电信领域。 随着 CSP 采用网络虚拟化来降低运营成本并加快新服务的部署，他们虚拟化了需要高吞吐量和/或低延迟的用例，例如路由器，防火墙，无线电访问网络（RAN）和演进的分组核心（EPC）。 虚拟化平台的供应商，在这些情况下，VNF 和应用程序已在其产品中利用了 DPDK，以实现 CSP 的性能目标。随着 CSP 探索新的边缘托管应用，例如视频缓存，监控，增强现实（AR），辅助驾驶，零售和工业物联网，DPDK 仍然是实现积极性能目标的关键技术。

类似 DPDK 最先在电信应用程序中， 对数据包处理功能的性能要求一样， DPDK 越来越多地应用于企业和云当中。 例如，在 2018 年，VMware 引入了他们的 NSX-T 数据中心软件定义基础结构的基于 DPDK 的边缘配置。 此版本的 NSX-T 地址需要具有可变数据包大小的高数据包吞吐量的应用程序以及支持具有以下功能的高速 NIC 的服务器高达 100Gbps 的北/南流量。 通常，南北向流的包大小各不相同，数据包处理要求，即使它们只占总流量的不到 20％。 在此用例中，通过使用带有小数据包（64 字节）的 DPDK，英特尔和 VMware 的分析表明，性能提高了五倍。

同时有几家公司已将 DPDK 用于金融应用，其中低延迟带来了巨大的竞争优势。 例如，在高频交易（HFT）中，延迟会直接影响交易者的交易效率 算法策略及其超越竞争对手的能力。 信息周刊估计，对于一家大型经纪公司来说，一毫秒每年价值 1 亿美元。 DPDK 是这个市场解决方案供应商开发所依赖的关键技术。

误区 #4 DPDK 只适用于电信行业

随着 NFV 的到来，DPDK 对于虚拟化网络功能的成功变得尤为重要，DPDK 可用于企业数据中心以及云服务提供商中部署的解决方案。 在 除了前面提到的各种用例之外，DPDK 的其他应用程序还包括虚拟交换，软件定义的网络（SDN），数据分析，人工智能（AI）推理，视频转码和在线赌博。 七大云提供商—阿里云，亚马逊网络服务，百度网盘，谷歌云平台，Microsoft Azure，腾讯云-所有产品都使用 DPDK。

DPDK 跨架构的快速增长

英特尔架构，AMD，ARM，Power 和 RISC-V

英特尔在 2010 年推出支持 x86 Xeon 平台的 DPDK 时，其他几家供应商也提供了多核面向网络应用程序的处理器及其自己的 SDK 库，以实现高性能数据包处理。 例如，Cavium 和 NetLogic 都推出了基于 MIPS CPU 架构的处理器，而飞思卡尔则是基于 PowerPC 架构的。在接下来的几年中，这三家公司都推出了基于 Arm 架构的新多核处理器系列。 有意思的是，随着半导体行业的持续发展，这三家公司最终都被收购了。 如今，面向高端网络应用的处理器的供应商格局已经逐步发展到市场领先的产品基于 Intel 和 AMD 的 x86 架构或包括 Broadcom，Marvell 和 NXP 在内的多家供应商提供的 Arm 架构。 IBM Power 体系结构用于适用于企业和云应用程序的处理器。 现在，DPDK 支持所有这三种架构，并在在添加开源 RISC-V 体系结构方面取得了进展。

作为 DPDK 的创始人，Linux Foundation 项目的金牌会员和领先的贡献公司之一，Intel 推动了 DPDK 中的许多创新，确保为所有相关的英特尔产品提供高度优化的支持，并且维护良好。 除了适用的 Xeon 处理器外，这些产品还包括网络适配器，例如 e1000，ixgbe，i40e，fm10k 和 ipn3ke。 DPDK 在 AMD 的 x86 处理器（例如 EPYC Embedded 3000 系列）上运行。 AXGBE 轮询模式驱动程序（PMD）提供支持集成在 EPYC SoC 中的 AMD 10Gbps 网络适配器系列。

OpenDataPlane 是第一个定义用于在基于 Arm 的 SoC 上进行网络数据平面处理的 API 的开源项目（ODP），由 Linaro Networking Group 在 2013 年发起。Linaro 是由 Arm，Freescale Semiconductor，IBM，三星，ST-Ericsson 和 Texas Instruments 于 2010 年成立的工程组织，致力于 Arm 的开源软件的开发。体系结构平台。 2018 年，Linaro Networking Group 解散，ODP 的管理移至 OpenFastPath（OFP）基金会，由 Arm，Enea 和 Nokia 于 2015 年成立。 启用与 DPDK，OFP 通过 ODP-DPDK 层实现了 DPDK 支持。

误区 #5 DPDK 是一个纯软件项目，是反硬件的

DPDK 最初是一个旨在通用 CPU 上提高 OS 的数据包处理性能的项目。它已经发展到远远不止于此了， 如今的 DPDK 更像是一个框架， 在 Linux 和其他 UNIX 类型的 OS 和 Windows 上的加速（请参阅http://doc.dpdk.org/guides/上列出的OS支持）。DPDK支持从SmartNIC到加密加速器的各种硬件设备。 它提供了一个统一的库可以在可用时利用硬件功能，但在硬件不可用时， 使用全软件路径的实现。 这样可以确保依赖 DPDK 的应用程序始终可以正确运行，尽管当没有独特的硬件加速挂钩时，性能会有所降低。

由于这两个 ODP-OFP 计划，Arm 体系结构在 DPDK 中具有强大的支持。 多个采用 Arm 执照的公司为 DPDK 做出了贡献，致力于确保 DPDK 利用该架构的所有功能。由某些 CSP 和设备提供商提倡，与具有相同功能的 x86 平台相比，其电源效率可能更高性能。 DPDK 中提供了对 IBM Power 架构的支持，并且最新的 DPDK 版本已合并 Power9 的库。 IBM 和 Canonical 合作开发了一个版本的 Ubuntu Server，可以直接从 IBM 订购，其中包括 DPDK 性能优化。

为了完善 DPDK 中支持的处理器体系结构，目前 DPDK 社区正在努力添加 RISC-V。RISC-V 基于 2010 年在伯克利的加利福尼亚大学开始的一个项目，是一个免费的开源指令集， RISC-V 基金会现在促进和维护体系结构（ISA）。 通过 2018 年宣布的合作，Linux Foundation 提供了 RISC-V 生态系统的资源，例如培训程序，基础架构工具和行销。 SiFive 是一家无晶圆厂的半导体公司，其基于 RISC-V 架构（例如 Freedom）生产 SoC， 并在 2016 年推出的 Everywhere 310 SoC。

鉴于其广泛的架构支持，DPDK 越来越不被视为 NFV 的加速器，而被视为 Linux 用户空间框架，为对高性能 I / O 和操作系统至关重要的核心功能提供统一的抽象层包处理，包括加密功能。DPDK 支持包括 FPGA，ASIC 和 SmartNIC 在内的各种硬件设备，从而充分利用了所有可用的，支持的资源，最大程度优化系统级别的整体网络性能。

误区 #6 DPDK 只与 Linux 相关

由于在数据中心内的广泛使用，DPDK 最初是在 Linux 上实现的。 但是，今天的 DPDK 支持更广泛的操作系统，例如 FreeBSD。 此外，DPDK 正在开发移植到 Windows 操作系统。

Open vSwitch 和 开放虚拟网络

Open vSwitch 是 Linux Foundation Networking 项目，是分布式虚拟多层的开源实现。使用 Apache 2.0 许可证。 它可以通过程序扩展实现大规模的网络自动化，同时仍支持标准管理接口和协议，例如 NetFlow，sFlow，IPFIX，RSPAN，CLI，LACP 和 802.1ag。 OvS 的 Linux 内核实现已于 2012 年合并到内核主线中。

最初英特尔与 OvS 社区接触，共同探索一种架构增强功能，该功能将使 DPDK 成为 OVS 额外的数据平面，但由于当时社区致力关注企业应用程序，认为这个主张的价值尚不明确，该建议也失败了。然后，根据 NFV 用例的性能要求，英特尔与两个电信客户合作创建了 DPDK。加速开放式 vSwitch，简称 ovs-dpdk，是 OvS 的分支，它利用 DPDK 优化了电信网络所需的流量以小数据包为主的 OvS 的性能。

2013 年，英特尔公开宣布 OVDK 为开放项目，并有外部贡献者的参与。 他们在 2014 年表示 OVDK 项目已达到演示所需性能加速的目标，并且 OVDK 将停止支持将 DPDK 集成到主线 OvS 代码库中，并致力于在 OvS 中保持这种支持。

到 2015 年，OvS-DPDK 已作为 OvS 的构建选项合并到主线中，从而提供了实施 OvS 中的用户空间数据平面（图 4）。 OvS-DPDK 的小数据包吞吐量提高了 10 倍以上，并且低得多的延迟。使用 DPDK 数据包处理还优化了 OvS 内部的几个性能热点区域库。开放虚拟网络（OVN）是一个开源项目，最初由 Nicira 的 OvS 团队于 2015 年启动（现在作为支持虚拟网络抽象的系统。 OVN 通过添加对虚拟网络抽象（例如虚拟第 2 层和第 3 层）的本地支持，对 OvS 的功能（包括 OvS-DPDK 配置）进行了补充覆盖和安全组。 OVN 的开源绑定可用于许多平台，例如 OpenStack 和 Kubernetes。 OVN 是许多商业产品中使用的 SDN 平台，包括 Red Hat Virtualization，Red Hat OpenStack 和 Red Hat OpenShift。 OvS-DPDK 为基于这些的部署带来了高数据包处理性能产品。

如今，对于大多数 NFV 部署，我们看到 OvS-DPDK 与 VNF 本身中启用的 DPDK 的组合（下图）。这提供了从 NIC 到应用程序的全程强大网络性能，同时保留了将 vSwitch 提供给可能相互通信的多个 VNF 的灵活性（东西向服务链接 Service Chain）。 正如我们将看到的，DPDK 可以用于多种部署架构中，并可以与其他方法结合使用加速，包括基于硬件的解决方法。

关开源项目和标准

尽管 DPDK 是软件加速工具包中最著名的一个，但也有其他开源项目和与 DPDK 重叠或相近的框架。 其中包括 Linux Foundation FD.io 的矢量处理平面（VPP）项目，以及 Linux Foundation ioVisor 项目中的 Express Data Path（XDP），以及 AF_XDP 和虚拟数据路径加速度（vDPA）。 还有 Snabb 数据包工具包和 netmap 项目，它们都采用类似的方法， 尽快将数据包移入用户空间。 尽管 Snabb 仍是一个活跃的项目，但由于 DPDK 的卓越的性能， 现在已基本取代了 netmap。

在 Linux 和其他 UNIX 风格的操作系统中，有许多方法可以改善网络性能。 从诸如将有效负载校验和添加到 NIC 的卸载功能到成熟的 TCP 卸载引擎（TOE）。 随着最近一波 NFV 工作负载的出现，人们对各种方法重新产生了兴趣，DPDK 只是其中一种。 为了简洁起见，我们将简要介绍不同的技术，并为读者提供有关 DPDK 当今适合的背景以及有关其他流行且有希望的网络加速计划的信息。我们将从硬件辅助机制开始，其中许多机制是 DPDK 的补充：

PCI 直通

PCI 直通涉及将 VM guest 虚拟机绑定到特定的 PCI 卡，就像 VM 是具有完全访问权限的裸机系统一样， 包括 NIC 的所有权。 可以使用类似的技术将特定的 NIC 绑定到容器。 这意味着没有 NIC 和网络应用程序的其他应用程序争用具有独占访问权。 数据包进入后 VM 或容器，它们仍必须在用户或内核空间中进行处理，但这是一个单独的考虑因素。

单根 I / O 虚拟化

单根 I / O 虚拟化（SR-IOV）是 PCI 标准的扩展，涉及创建虚拟功能（VF），该功能可以被视为独立的虚拟 PCI 设备。 可以将每个 VF 分配给 VM 或容器，并且每个 VF 具有传入数据包的专用队列。 同样，数据包到达后如何处理是一个单独的决定。 SR-IOV 是通常在实际部署中与 DPDK 结合使用，目标是绕过主机和来宾 OS 的内核。它可用于提供从 VNF（VM）中的用户空间到虚拟接口上的传入数据包队列的直接访问在 NIC 上，减少了等待时间，并减少了复制过程（图 6）。 容器可以使用相同的技术。 主要的 SR-IOV 的问题在于它需要支持该功能的 NIC，并且每个 VF 都占用 NIC 上的物理资源，因此虽然理论上 VF 限制很高，但实际上可以限制多少个 VF 存在实际的内存限制。

FD.io/VPP

矢量数据包处理器（VPP）是 Linux Foundation 下的 Fast Data（FD.io）项目的一部分。 VPP 最初是由思科作为一个开源项目贡献。 VPP 的目标是提供一个快速的 2-4 层用户空间网络堆栈，在 x86，Arm 和 Power 等常见架构上运行。如今，大多数 VPP 实施都利用 DPDK 作为插件，加速通过 DPDK PMD 将数据包进入用户空间。VPP 专注于上层网络协议（下图）。 VPP 通过在以下位置执行功能来获得其大部分性能分批或矢量分组，而不是单个分组。 VPP 为第 2 层和第 2 层提供了虚拟交换机和虚拟路由器第三层数据包处理。它还集成了优化的 TCP / IP 堆栈，该堆栈使用矢量化数据包处理来提高性能。性能。与使用 DPDK 相比，这使在 VPP 之上构建高层（L4-7）网络功能更加容易。VPP 专注于招募虚拟网络网关和安全性等上层网络功能的开发人员。它还正在努力确保使用容器的云原生平台可以有效地使用 VPP。

XDP 和 eBPF/BPF

eXpress 数据路径是 ioVisor 项目下的内核中数据包处理框架，该框架也由 Linux 基金会托管。它旨在在内核空间中提供高性能的数据包处理。 XDP 通过挂钩实现了这一目标，进入内核以对传入的数据包运行优化的代码。这些程序在扩展的伯克利分组过滤器（eBPF）框架下执行。 eBPF 是 1992 年创建的原始 BPF 内核解决方案的改进版本，该解决方案利用了有限的机器指令集，以在内核空间中运行用户创建的程序，基本上在轻量级虚拟机中运行。在将这些用户程序加载到内核之前，已经过验证，以确保它们没有恶意，并且不会无休止运行。 BPF 的最初用途是通过过滤进行网络故障排除和分析，不久将扩展到安全用例。 eBPF 诞生于 2013 年，是对原始 BPF 的改进，并引入了更复杂的虚拟机。通过低级虚拟机 LLVM）将 eBPF 用户程序编译为 eBPF 指令，然后加载到内核中执行。今天，我们使用术语 BPF 来指代 eBPF，将旧的 BPF 降级为经典的 BPF。

因此，XDP 方法通过运行自定义逻辑来处理内核中的数据包来实现性能（下图）。 XDP BPF 和 BPF 已用于创建复杂的网络解决方案，包括 Cilium 等安全项目。 以内核内方法与内核旁路方法不同，XDP 能够在处理数据包的同时利用内核网络堆栈。 它正在积极开发中，在除了删除，切换或传递到内核堆栈之外， 增加复杂动作的同时改善其性能。

AF_XDP

AF_XDP 代表地址族 XDP，这是 Linux 中新的套接字地址族类型。 AF_XDP 与 XDP 有关，因为它使用 eBPF 机制以及 VXP 驱动程序层。 它会将符合特定条件的数据包直接引导到用户空间中。类似于 DPDK 的内核绕过。 当与 XDP 结合使用时，这种方法结合了最好的内核逻辑使用 DPDK 样式的内核绕过。 AF_XDP 套接字允许内核 XDP 程序将帧重定向到用户空间中的缓冲区进行处理，或继续通过内核的现有网络堆栈，TCP / IP 等分流一些流量（下图）。

目前 AF_XDP 还无法达到 DPDK 所能提供的高性能水平，该项目得到了英特尔，红帽和 Mellanox 等供应商的支持。 其中一个 AF_XDP 方法的潜在主要优点是减少了对特定于供应商的 PMD 的需求，而是允许构建与基础网卡无关的便携式网络功能应用程序。 实际上，DPDK 该项目使用 AF_XDP 驱动程序框架来简化大量特定于供应商的 PMD，从而提供了没有本地分叉的设备的模型。

vDPA

virtio 数据路径加速（vDPA）项目（有时称为“虚拟”或“ vhost”数据路径加速）目的是标准化 NIC SR-IOV 数据平面。 它使用了众所周知的 virtio 框架，利用了来宾 VM 中的 virtio 驱动程序（图 10）或容器中 DPDK 的 virtio 用户 PMD，两者均与供应商无关。 在下面在 vDPA 框架中，每个 NIC 供应商都将遵循 virtio 环布局进行数据通信。 他们还将提供供应商 vDPA 驱动程序，可帮助 DPDK 将控制平面指令转换为供应商特定的控制平面命令。 目标是以减少 DPDK 下必须维护的大量特定于供应商的驱动程序（PMD）。 像 AF_XDP 一样，它通过减少供应商驱动程序的依赖性，提高网络功能的可移植性。

vDPA 仍处于早期阶段，并且正在积极开发中。 它得到了主要供应商的支持，例如英特尔，Mellanox 和红帽

Switchdev 和 Linux 内核

以太网交换机设备驱动程序模型（switchdev）是用于减轻数据平面负担的内核设备模型的框架从内核到交换 ASIC 的流量。switchdev 的目标是允许用户使用 Linux 内核之上的著名 API 访问现有的 ASIC 功能。然后，这些用户可以使用相同类型的命令和工具来配置服务器或交换机。在 switchdev 下模型，而不是将数据包移至用户空间或在内核空间中对其进行处理，可以将数据包处理分流到 NIC 卡上的 ASIC 或机架顶部的外部交换机，它们在硬件中执行高速交换功能。

尽管有新方法可以改善数据包处理性能，但 DPDK 仍然是最受欢迎的方法并被广泛采用。 DPDK 社区还积极与许多其他举措进行合作，包括 VPP，AF_XDP 和 vDPA 将继续发展 DPDK，并提高其性能和易用性。

误区 #7 DPDK 仅对硬件供应商感兴趣

是的，DPDK 中涉及许多硬件供应商。 但是，DPDK 有很多甚至更多的服务供应商，系统集成商，最终用户和软件开发人员。

基础设施的加速趋势促进 DPDK 的发展

随着媒体器件更高分辨率的需求，物联网设备的数据收集量的增加， 加上对业务的大数据和 AI 分析的日益增长，使得数据中心在数量和规模上都在不断增长。同时围绕 5G 的市场计划，云和电信市场都看到了关于物联网和边缘计算的新的需求： 虚拟化无线接入网络和电信中心局（CO）将商品服务器推向了新的边缘位置。在 x86 或 Arm 系统上运行的 Disaggreated RAN，处理视频分析的边缘工作负载以及运行的边缘系统， 内容交付网络等都要求更高的网络速度和 I / O 处理能力。同时随着对隐私的不断关注以及需要防止对通信流进行的恶意攻击，加密已经变得至关重要。当把将这些需求添加到对电源，冷却和空间的日益严格的限制中时，对于 DPDK 或其他提高数据包处理效率的方法的需求就变得越来越强烈。

误区 #8： DPDK 不够绿色，它一直占用 CPU 的资源

DPDK 现在主要依赖于 PMD 来提高性能，并且因为驱动程序不断以 polling 的模式查看数据包是否已经到达，这样即使在没有数据包的时候，CPU 也会 100％的时间处于繁忙状态。 这个现象使得有些人相信 DPDK 不是绿色的。 但是从另一个角度看，DPDK 允许电信基础设施提高其现有平台的效率，减少了对额外 CPU 的需求，同时也提高了数据包处理能力。 目前 DPDK 团队正在研究通过扩展核心频率以减少空闲流量时段的功耗的方法，例如允许 CPU 通过 Rx 中断唤醒的 API。

FPGA，ASIC，GPU 与 DPDK 的关系

在运行移动工作负载的边缘无线网关和安全设备中，例如虚拟演进分组核心（vEPC）， 大多数网关功能都涉及摄取数据包，检查报文头和有效负载以及执行某些操作。 DPDK 非常适用于这些用例，特别是考虑到它在不同 CPU 类型（x86，Arm）上运行的灵活性，尤其如此。当我们更详细地检查这些边缘位置时，我们发现设备类型和新硬件的多样性在增加，功能包括 FPGA，GPU，NPU 和自定义 ASIC。 DPDK 必须不断地发展以适应这些特殊的 NIC 以及融合那些看起来可能与当今数据中心标准服务器不同的基础架构系统。在当今的云数据中心内，SmartNiC 被越来越多地采用来分担 I/O 的处理。

在节约成本和功耗的驱动下，我们希望数据包的低层处理可以转移到硬件上，诸如 FPGA，ASIC 或 NPU 的同类产品。 简单的交换机，防火墙，基本的负载平衡或路由功能可能不需要通用 CPU 编程和灵活性。 但是，对于更复杂的 L4-7 功能，DPDK 在有效地将数据包发送到用户空间以使应用程序执行更深入的分析中发挥关键的作用。 例如，任何类型涉及 L7 代理中的 HTTP 标头检查和注入或有效负载处理时，都会更加倾向于使用 DPDK。

FPGA / ASIC 之间的协作安全解决方案也在不断地发展，其中数据包通过 DPDK 进入用户空间进行分析。 一旦确定流是安全的，FPGA 和 ASIC 便能够直接引导流而无需涉及 CPU 周期。在 GPU 方面，我们看到了一些方法，例如 Nvidia 的并行计算平台 CUDA 与虚拟技术的结合。网络功能（cuVNF），可直接将有效载荷直接复制到 GPU 图形内存中，以进行信号处理 vRAN 解决方案。 不过这些还在早期发展阶段，与 DPDK 的关系会在未来几年有所发展。

误区 #9: DPDK 的代码已经完成

DPDK 是一个正在进行和发展的项目，每年都要发布四个版本。 DPDK 将继续根据用户的新需求，引入新的加速器设备，增加支持容器部署以及对其他设备的扩展，还有安全性和存储功能的扩展。

DPDK 加速器功能： RegEx，Compress Dev，SPDK 等

行业中的许多人将 DPDK 视为内核绕过机制，因其将数据包快速引进用户空间。 DPDK 框架其实要比这丰富得多。 DPDK 已经发展成为本质上可以加速使用的通用 API 基础平台的功能，包括通用 CPU 和其他功能（例如密码功能）。DPDK 包括其他用于压缩和存储的库，以及正在开发中的正则表达式匹配（RegEx）的库。 我们把这些 DPDK 新兴库做一个简要说明：

• RegEx：一个 DPDK 子系统，用于提供对正则表达式的加速匹配，常用于报文头部和用于安全性和 L7 负载平衡功能的有效负载匹配。

• CryptoDev：加速安全功能的库，提供诸如 Hashing 和公钥/私钥操作。

• CompressDev：一个可以方便地访问常见的压缩算法，同时支持两种无状态压缩和有状态压缩有助于减少有效负载大小，同时减轻 CPU 负担的库。

• bbdev：无线基带库提供了抽象硬件的通用编程框架，基于 FPGA 的加速器和/或辅助 3GPP 物理层处理的固定功能加速器，同时通过抽象化应用程序的优化功能将其与计算密集型无线功能分离库显示为虚拟 bbdev 设备。

除了 DPDK 系列之外，还有存储性能开发套件（SPDK），该套件使用一些 DPDK 代码。尽管本身不是 DPDK 项目，但他们正在采用类似于 DPDK 的存储协议方法，试图加快存储速度，通过使用类似的 PMD 来实现 I/O 功能， 通过将存储协议直接带入用户空间，类似 DPDK 在网络方面的提升， 来实现存储方面的性能提升。 SPDK 使用非易失性快速存储器（NVMe），用户空间中具有光纤 NvME（NVMe-oF）和存储协议 iSCSI 堆栈的标准 PMD 来提高存储系统的性能。

DPDK 和 Linux 容器

DPDK 最初设计是针对具有虚拟机的环境，在裸机部署和虚拟机中均能很好地工作。 DPDK 如今可以用于容器，对容器的支持也在不断地改善。当前容器环境中存在一些限制，例如需要为容器分配大量静态内存，数据包缓冲区，这使其不适用于临时的小规模微服务组件。 最新的 DPDK 版本解决了此问题，实现了增强的动态内存分配的功能。

对于 DPDK 在容器启用特权的上下文的安全性一些开发人员表达了担忧， 这可能会增加底层操作系统的受攻击可能性，并且 DPDK 可能仅仅只能在使用受信任的工作负载的平台中方可运行。 不过，DPDK 开发人员正在解决这些问题，我们期望 DPDK 的容器支持随着容器在现代云原生架构中的兴起，并随着时间的推移而不断地改善。

DPDK 的优势与提高

随着 SmartNIC 的出现，曾经有一些业内人士预测 DPDK 会逐渐消失。 然而事实是，DPDK 依然在不断地发展，并且工作也在加速。 展望未来，我们看到 DPDK 具有以下优势，以及需要提高的地方：

• 成熟性和稳定性： API 的稳定性是当今 DPDK 的独特属性之一。 不像其他加速方案，DPDK 相对成熟，项目维护人员了解保持需求的必要性，可靠的 API，以防止代码损坏或持续的补丁程序和重新编译。

• 持续的性能改进： DPDK 将继续寻找方法和智能网卡 SmartNIC 和其他硬件加速的整合与集成。 同样，我们可以期待 DPDK 继续在软件性能上的改进。

• 降低复杂性：DPDK 并不是最容易部署和使用的，而且还必须包含多个组件的正确配置和部署，例如带有 VNF 并支持 DPDK 的 OVS-DPDK。 此外，还有无数必须维护的供应商特定的 PMD。 供应商并不想维护多个驱动程序，无论 AF_XDP 统一 PMD 是否成功，DPDK 都需要更标准化的方式与硬件集成。

• 更好的云和容器支持：今天 DPDK 虽然支持容器，但还并不理想。 预期在用于容器部署的 DPDK 内存管理中 DPDK 会进行改进，来更好地与容器和微服务架构对齐。 同样，安全模型也需要加强，以避免使用 DPDK 的容器需要特权升级。

• 效率更高： 在 Arm 架构上，支持事件触发模式以提取数据包（相对于常量在 x86 上轮询）。 这样的方法以及时钟 CPU 缩放将有助于 DPDK 改善其非绿色声誉。

• 多供应商：期望在 x86 以外的各种指令体系中继续提供支持（英特尔和 AMD），Arm 和 PowerPC。 同样，英特尔等供应商提供的加密和其他加速功能，也在 Mellanox 和 Marvell 以及其它新兴硬件供应商中得到进一步支持和发展。

• 最佳实践的合理化和规范化： 虽然 2020 年将出现不同的用例和体系结构， 但无论是使用在 SmartNIC 本身上使用 DPDK 或由 API 驱动模型中 DPDK 调用 SmartNIC 加速的技术，DPDK 与 SmartNIC（FPGA，ASIC，NPU）相结合的最佳实践方式的发展都将会继续下去。

无论如何，DPDK 会继续成为基础设施加速中的主导框架，而 DPDK 项目也在寻找更多的贡献者和支持者。 和所有开源项目一样，只有通过各种社区人员的参与才能成功。无论您是软件开发人员还是硬件开发人员，质量检查人员，开发测试工程师，文档专家或市场营销专家，DPDK 该项目正在寻找新的贡献者和成员。 如果需要了解更多信息，请访问Linux Foundation DPDK网站查看详情。