目录
DPDK 优化技术
- DPDK 性能影响因素
- - 硬件结构的影响
  - OS 版本及其内核的影响
  - OVS 性能问题
  - 内存管理
  - CPU 核间无锁通信
  - 设置正确的目标 CPU 类型与模式
- 优化方案
- - 应用 NUMA 亲和性技术减少跨 NUMA 内存访问
  - 应用 CPU 绑核技术减少上下文切换损耗
  - 应用大页内存技术减少 TLB miss

DPDK 优化技术

DPDK 优化技术指在 DPDK 应用过程中，为进一步提高各类用户应用程序的转发性能，所采取的性能调优方法和关键配置。

我们可以列出 DPDK 的优化方法有（包含但不限于）：

Bypass 内核协议栈。通过 uio/vfio 将网络设备暴露给 userspace（uio/vfio 是 Linux Kernel 支持用户层驱动的编程框架）。
使用 HugePage 从而大大降低 TLB miss 带来的性能损失。
广泛的应用批处理从而摊薄单个报文的开销（e.g. 使用 simd 优化网卡驱动）。批处理的优化思想在 DPDK 之中是一个极其常见的范式。
放弃中断模式而转而直接使用轮询模式。这个对于降低时延非常重要。因为在 PCIE 总线上，中断也是一个 TLP，报文过多的中断也会影响真正数据的时延（尤其是小包），中断处理导致的上下文切换也会引起系统抖动。但是轮询非常考验内存控制器和 PCIE Root Complex 的鲁棒性。鲁棒性差的平台容易出问题。
网卡直接 DMA 数据到 LLC（Last-Level Cache）中。DDIO 对于小包的性能非常重要，这个在今天依然是 Xeon CPU 的独有功能（新一代的 CLX 协议中实现了 DDIO 的超集）。
对齐对齐再对齐。预取预取再预取。极度重视 Cache 的优化。对齐主要是针对 CacheLine 长度以及 PCIE 的 DMA 地址。预取（Prefetch）则较为难以把握精确的时间点，需要反复的实验找到最佳位置。
隔离 Core，不让 Core 参与操作系统的调度。减少抖动。禁止进程切换，尽量减少系统调用，这些都会引起严重的抖动。
广泛使用二阶递进的分区设计模式。尽量避免核间通信（e.g. mem pool/local pool etc）。
广泛使用无锁队列以及相关精巧的数据结构设计。例如：rte_ring。

经过这样层层递进联合的优化， DPDK 终于站上了性能的巅峰。

DPDK 性能影响因素

本节主要介绍基于 DPDK 进行应用开发和环境配置时，应用程序性能的影响因素以及相应的优化调整方法。这些因素并非必然劣化性能，可能因硬件能力、OS 版本、各类软硬环境参数配置等的差异产生较大波动，或者存在较大的不稳定性，相关的调优方法需要用户结合自身的 VNF 应用部署在实践中不断完善。

硬件结构的影响

DPDK 具有广泛的平台适应性，可以运行在整个 x86 平台，从主流服务器平台（从高性能或者高能效产品系列），到桌面或者嵌入式平台，也可以运行于基于 Power 或者其他架构的运算平台。下图展示了一个通用双路服务器的内部架构，它包含了 2 个中央处理器，2 个分离的内存控制单元来连接系统内存，芯片组会扩展出大量高速的 PCIe 2.0/3.0 接口，用于连接外设，如 10Gbps 或者 25Gbps 网卡外设。

硬件规格对 DPDK 性能的影响体现在几个方面：

CPU 频率：CPU 频率越高，DPDK 性能越高。
LLC（Last Leve Cache）大小：缓存越大，DPDK 性能越高。
PCIe Lane 的数目：PCIe 链路可以支持 1、2、4、8、12、16 和 32 个 Lane，需要确保其带宽可以满足所插网卡的带宽。
NUMA：网络数据报文的处理由网卡所在的 NUMA 节点处理，将会比远端 NUMA 节点处理的性能更高。

OS 版本及其内核的影响

不同的 Linux OS 发行版使用的 Linux 内核版本不一样，配置的 Linux OS 服务也不一样。这些差异都会导致应用程序在网络报文处理能力上有所差别。由于 Linux 内核还在不断演进，Linux 的发行版也数量众多，同样的硬件配置环境下，不同的 Linux 发行版在小包的处理能力上存在差异。本文无法提供最佳 Linux 内核版本和配置，而只能给出部分参考建议，如：关闭部分 OS 服务。

OVS 性能问题

OVS 作为 NFV 的一个重要组成模块，会运行在绝大多数的服务器节点上，提供虚拟机和虚拟机之间，以及虚拟网络和物理网络间的互连接口，其性能至关重要。OVS 2.4 开始正式支持 DPDK 加速，相比传统基于 Linux 内核的 OVS 版本，转发性能提高了数倍，为 VNF 在通用 x86 服务器上部署提供了有力支持。

OVS 缺省会为每一个 NUMA 节点创建一个 pmd 线程，该 pmd 线程以轮询方式处理属于其 NUMA 节点上的所有 DPDK 接口。为了高性能，需要利用前面提到的 CPU 绑核技术，把 pmd 线程绑定在一个固定的 CPU core 上处理。此外，为了增加扩展性，OVS 2.4 也支持网卡多队列以及多 pmd 线程数，这些参数均可动态配置，但具体配置应根据具体需求来决定。

内存管理

如前所述，DPDK 考虑了 NUMA 以及多内存通道的访问效率，会在系统运行前要求配置 Linux 的 HugePage，初始化时申请其内存池，用于 DPDK 运行的主要内存资源。Linux 大页机制利用了处理器核上的的 TLB 的 HugePage 表项，这可以减少内存地址转换的开销。

CPU 核间无锁通信

如果想建立一个基于消息传递的核间通信机制，可以使用 DPDK Ring API，它是一个无锁的 ring 实现。该 Ring 机制支持批量和突发访问，即使同时读取几个对象，也只需要一个昂贵的原子操作，批量访问可以极大地改善性能。

设置正确的目标 CPU 类型与模式

DPDK 支持 CPU 微架构级别的优化，可以通过修改 DPDK 配置文件中的 CONFIG_RTE_MACHINE 参数来定义。优化的程度根据随编译器的能力而不同，通常建议采用最新的编译器进行编译。如果编译器的版本不支持该款 CPU 的特性，比如 Intel AVX 指令，那么它在编译时只会选用自己支持的指令集，这可能导致编译后生成的 DPDK 应用的性能下降。

优化方案

笔者在 DPDK 的优化方面的实践因为商业敏感的问题，本文不便提及。网上有很多资料，推荐阅读这一篇文章 https://zhaozhanxu.com/2016/08/09/DPDK/2016-08-09-dpdk-optimization/ 和《DPDK 技术白皮书》。

应用 NUMA 亲和性技术减少跨 NUMA 内存访问

在 NUMA（Non-Uniform Memory Access，非一致性存储器访问）架构的处理机中，CPU 访问本地内存（同 NUMA）和远程内存（跨 NUMA）的耗时并不相同，NUMA “非一致性存储器访问” 架构由此得名。

NUMA 的结构设计能够在一定程度上解决 SMP 低存储器访问带宽的问题。假如一个 4 NUMA 节点的系统，每一个 NUMA 节点内部都具有 1GB/s 的存储带宽，外部共享总线也同样具有 1GB/s 的带宽。理想状态下，如果所有的 CPU 总是访问本地内存的话，那么系统就拥有了 4GB/s 的存储带宽能力。此时的每个 NUA 节点都可以近似的看作为一个 SMP（这种假设为了便于理解，并不完全正确）；相反，在最不理想的情况下，如果所有处理器总是访问远程内存的话，那么系统就只能有 1GB/s 的存储器访问带宽。

除此之外，使用外部共享总线时可能会触发 NUMA 节点间的 Cache 同步损耗，这会严重影响内存密集型工作负载的性能。当 I/O 性能至关重要时，外部共享总线上的 Cache 资源浪费，会让连接到远程 PCIe 总线上的设备（不同 NUMA 节点间通信）作业性能急剧下降。

由于这个特性，基于 NUMA 架构开发的应用程序应该尽可能避免跨 NUMA 节点的远程内存访问。因为，跨节点内存访问不仅通信速度慢，还可能需要处理不同节点间内存、缓存的数据一致性问题。多线程在不同 NUMA 节点间的切换，是需要花费大成本的。

应用 CPU 绑核技术减少上下文切换损耗

现代操作系统都是基于分时调用方式来实现任务调度，多个进程或线程在多核处理器的某一个核上不断地交替执行。每次切换过程，都需要将处理器的状态寄存器保存在堆栈中，并恢复当前进程的状态信息，这对系统其实是一种处理开销。将一个线程固定一个核上运行，可以消除切换带来的额外开销。另外将进程或者线程迁移到多核处理器的其它核上进行运行时，处理器缓存中的数据也需要进行清除，导致处理器缓存的利用效果降低

CPU 亲和技术，就是将某个进程或者线程绑定到特定的一个或者多个核上执行，而不被迁移到其它核上运行，这样就保证了专用程序的性能。DPDK 使用了 Linux pthread 库，在系统中把相应的线程和 CPU 进行亲和性绑定，然后相应的线程尽可能使用独立的资源进行相关的数据处理。

应用大页内存技术减少 TLB miss

处理器的内存管理包含两个概念：物理内存和虚拟内存。Linux 操作系统里面整个物理内存按帧（Frames）来进行管理，虚拟内存按照页（Page）来进行管理。内存管理单元（MMU）完成从虚拟内存地址到物理内存地址的转换。内存管理单元进行地址转换需要的信息保存在
一个叫页表（Page Table）的数据结构里面，页表查找是一种极其耗时的操作。为了减少页表的查找过程，Intel 处理器实现了一块缓存来保存查找结果，这块缓存被称为 TLB（Translation Lookaside Buffer），它保存了虚拟地址到物理地址的映射关系。所有虚拟地址在转换为物理地址以前，处理器会首先在 TLB 中查找是否已经存在有效的映射关系，如果没有发现有效的映射，也就是 TLS miss，处理器再进行页表的查找。页表的查找过程对性能影响极大，因此需要尽量减少 TLB miss 的发生。

x86 处理器硬件在缺省配置下，页的大小是 4K，但也可以支持更大的页表尺寸，例如 2M 或 1G 的页表。使用了大页表功能后，一个 TLB 表项可以指向更大的内存区域，这样可以大幅减少 TLB miss 的发生。早期的 Linux 并没有利用 x86 硬件提供的大页表功能，仅在 Linux 内核 2.6.33 以后的版本，应用软件才可以使用大页表功能。DPDK 则利用大页技术，所有的内存都是从 HugePage 里分配，实现对内存池（Mempool）的管理，并预先分配好同样大小的 mbuf，供每一个数据包使用。

DPDK 目前支持了 2M 和 1G 两种 HugePage。通过编辑 /etc/grub.conf 来设置：

default_hugepagesz=1G hugepagesz=1G hugepages=32 isolcpus=0-22

然后，执行下述指令，将 HugePage 文件系统 hugetlbfs 挂载到 /mnt/huge 目录：

mount –t hugetlbfs nodev /mnt/huge

如此，用户进程就可以使用 mmap() 系统调用映射 HugePage 目标文件来使用大页面了。测试表明应用程序使用大页表比使用 4K 的小页表性能提高 10%~15%。

NOTE：大页内存的具体介绍可以参见 Linux 的大页表文件系统（hugetlbfs）特性。

DPDK — 数据平台优化技术相关推荐

兼顾稳定和性能，58大数据平台的技术演进与实践
http://www.infoq.com/cn/articles/58-big-data-platform-technology 主要内容分为三方面:58大数据平台目前的整体架构是怎么样的:最近一年半 ...
稳定和性能如何兼顾？58大数据平台的技术演进与实践
作者|赵健博编辑|尚剑本文将为你分享58大数据平台在最近一年半内技术演进的过程,包括:58大数据平台目前的整体架构是怎么样的:最近一年半的时间内我们面临的问题.挑战以及技术演进过程:以及未来的规划 ...
诸葛io的技术架构图_大数据平台的技术演化之路诸葛io平台设计实例
作者简介:本文来自诸葛io创始人孔淼的技术分享.诸葛io是业内领先的智能数据决策平台,也是国内早期的数据分析践行者.本文将从诸葛io平台设计实例,分享大数据平台的技术演化之路. 如今,数据分析能力正逐 ...
大数据平台架构技术选型与场景运用
内容来源:2017年5月6日,大眼科技CTO张逸在"魅族技术开放日第八期--数据洞察"进行<大数据平台架构技术选型与场景运用>演讲分享.视频地址:https://mp. ...
你理解常见如阿里，和友商大数据平台的技术体系差异以及发展趋势和技术瓶颈，在存储和计算两个方面进行概述
题目: 你理解常见如阿里,和友商大数据平台的技术体系差异以及发展趋势和技术瓶颈,在存储和计算两个方面进行概述. 参考答案:开放性问题,无标准答案.
《智慧城市时空大数据平台建设技术大纲（2019版）》解析——未完，待续
2月18日,自然资源部办公厅发布关于印发<智慧城市时空大数据平台建设技术大纲(2019版)>我们先来回顾下之前国家对于智慧城市建设的指导性纲要文件: 1.2015年,<智慧城市时空信 ...
智慧城市时空大数据平台建设技术大纲（2019版）
智慧城市时空大数据平台建设技术大纲(2019版) 参考地址:http://gi.mnr.gov.cn/201902/t20190218_2395831.html 智慧城市时空大数据平台建设技术大纲.d ...
金融大数据平台总体技术要求
本文件规定了面向金融业的大数据平台总体技术要求的框架结构.功能技术要求.非功能技术要求以及接口技术要求. 关注公众号:[互联互通社区],回复[DATA065]获取全部报告内容. 精彩推荐关注互联互通 ...
《离线和实时大数据开发实战》（二）大数据平台架构技术概览
前言接着上一章构建大数据开发知识体系图谱,本次继续分享邦中老师的<离线和实时大数据开发实战>读书笔记 .到底什么样的平台才能算是大数据平台呢?带着这个问题,我们开始今天的内容 ( •̀ ...

DPDK — 数据平台优化技术

目录

文章目录