dpdk详解_没有dp协议的typec

请问高性能计算的学习路线应该是怎样的？ 　　第一次在知乎提问，如果有描述不准确或不恰当的地方还请多多指教。本人现在本科毕业，即将去日本留学，研究室的主要方向是GPGPU的高性能计算。在看过研究室（主要是BOSS）发表的引用前十的论文，以及世界上的相关文章之后愈发迷茫。目前了解到的情况是需要模拟电路、数字电路、CUDA编程等相关知识。由于本科学校比较渣，没有进过实验室，也从未有相关的GPU集群等实验环境。想请问各位，如果想深入学习的话，学习路线应该是怎样的？有幸拜读过徐明强大大的微软高性能计算服务器，请问微软的高性能计算组也是研究类似的么？Thanks in advance,以上 　　一、DPDK基础原理 　　Intel DPDK全称Intel Data Plane Development Kit，是intel提供的数据平面开发工具集，为Intel architecture（IA）处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持，它不同于Linux系统以通用性设计为目的，而是专注于网络应用中数据包的高性能处理。DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包，绕过了Linux内核协议栈对数据包处理过程。Linux内核将DPDK应用程序看作是一个普通的用户态进程，包括它的编译、连接和加载方式和普通程序没有什么两样。DPDK程序启动后只能有一个主线程，然后创建一些子线程并绑定到指定CPU核心上运行。 　　1.1 产业背景 　　因特网和其他互联网必须承载的通信量在持续增长和变化。如今，实时响应的万维网的广泛使用和音频、图像、视频的使用增长，驱动了服务质量需求的增长。为了应对这种增长，TCP/IP体系结构发展了QoS（服务质量）以支持各种类型的拥有各种服务质量需求的通信量。数据平面(Data Plane)是QoS框架的三平面之一，承担了通信中分组的队列管理，排队调度，拥塞避免等直接在数据流上进行操作的机制，对提高网络通信的效率起着至关重要的作用。 　　在此基础上，人们期望用更低的成本和更短的产品开发周期来提供多样的网络单与丰富的功能，如应用处理、控制处理、包处理、信号处理等。为了适应这一新的产业趋势，基于Intel x86架构的DPDK面世了。 　　DPDK是一个linux基金会的开源项目。 开发DPDK的主要目的，是在数据平面应用中为快速的数据包处理提供一个简单而完善的架构。在理解此工具集之后，开发人员可以以此为基础进行新的原型设计，或简单地为我所用。 　　DPDK架构通过创建EAL(Environment Abstraction Layer,环境抽象层)来为不同的工作环境创造函数库集，创建后开发者即可把自己的应用与函数库进行链接。该架构也包含跟踪调试，PCIe总线接入等功能，并有相关样例帮助开发者学习如何使用这些功能。 　　1.2工作环境 　　DPDK的环境抽象层向应用与函数库隐藏了底层环境的细节，因而能扩展到任何处理器上使用。就操作系统来说，它提供了对Linux和FreeBSD的支持。 　　1.3工作原理 　　DPDK使用了轮询(polling)而不是中断来处理数据包。在收到数据包时，经DPDK重载的网卡驱动不会通过中断通知CPU，而是直接将数据包存入内存，交付应用层软件通过DPDK提供的接口来直接处理，这样节省了大量的CPU中断时间和内存拷贝时间。 　　1.4关键技术 　　环境抽象层 　　DPDK的创造的环境抽象层(EAL, Environment Abstraction Layer)主要负责对计算机底层资源（如硬件和内存空间）的访问，并对提供给用户的接口实施了实现细节的封装。其初始化例程决定了如何分配这些资源（PCI设备、计时器、控制台等）。 　　EAL提供的典型服务包括：加载和启动DPDK：DPDK及其应用程序会被链接为单一应用，因此需要通过某种方式进行加载DPDK。核关联/分配过程：EAL提供了将执行单分配给特定核并创建执行实例的机制。预留系统内存：EAL为预留不同的内存区域提供便利，例如用于设备交互的物理内存区域。抽象PCI地址：EAL提供了访问PCI地址空间的接口。跟踪和调试功能：日志、堆栈转储等。实用的功能：libc中所没有提供的自旋锁和原子计数器。CPU功能识别：在运行时确定CPU是否支持特定功能，确定当前CPU是否支持编译产生的二进制指令集。中断处理：向特定中断源注册/注销回调的接口。时钟功能：用于设置/删除在特定时间运行的回调函数接口。 　　轮询模式驱动 　　DPDK包括1Gb,10Gb,40Gb和半虚拟化抽象层的轮询模式驱动(PMD, Poll Mode Driver)。PMD由用户空间的特定的驱动程序提供的API组成，用于对设备和它们相应的队列进行设置。抛弃了基于中断的异步信号发送机制为该架构带来很大的开销节省。避免中断性能瓶颈是DPDK提升数据包处理速度的关键之一。 　　DPDK环境为数据包处理应用考虑了两种模型：运行至完成(run-to-completion)模型和管道(pipeline)模型。在运行至完成模型中，一个API向某个特定端口的接收描述符环轮询以接收数据包。接着这个数据包在同一个核上被处理，之后被一个发送用API放到端口的传输描述符环上；在管道模型中，一个核心会通过API对一个或多个端口的接收描述符环进行轮询，数据包通过环被接收和传递给另一个核心，然后在这个核心上被处理，之后可能被发送用API放到端口的传输描述符环上。 　　运行至完成是一个同步模型，每个指派给DPDK的逻辑核心执行如下所示的循环：通过PMD接收用API来提取输出数据包根据转发，一一处理收到的数据包通过PMD发送用API发送输出数据包 　　相反，管道模型是一个异步模型，有的逻辑核心只执行数据包提取，而有的只执行处理，收到的数据包在这些逻辑核心之间通过环来传递。 　　提取核心执行如下的循环：通过PMD接收用API来提取输出数据包通过队列提供数据包给处理核心 　　处理核心执行如下的循环：从队列中提取数据包根据重传（如果被转发）处理数据包 　　为了避免不必要的中断性能瓶颈，执行环境禁止任何异步通知机制的使用。在任何需要或合适的时候，异步通信都应尽可能采用环的方式。 　　在多核环境中避免锁竞争是一个重要的问题。为了处理这个问题，PMD被设计为可以尽可能地在单核私有资源下工作。例如，PMD为每个核心每个端口提供一个单独的队列。同样的，每个端口的接收队列只会被指派给唯一一个逻辑核心并接收它的轮询。 　　还不熟悉的朋友，这里可以先领取一份dpdk新手学习资料包（入坑不亏）：

　　DPDK技术交流群（）：正在跳转 　　DPDK学习地址：Dpdk/网络协议栈/vpp/OvS/DDos/NFV/虚拟化/高性能专家 　　1.5DPDK开源社区 　　不久前，DPDK官方社区正式发布23.03版本，芯启源代码贡献率位居全球第六，截止到此版本，芯启源DPDK开源社区代码贡献率一直稳居国内前二。

　　值得回顾的是在DPDK 2022年底正式发布的年终版本22.11中，芯启源代码贡献率位居全球第四。前六名分别为Intel、Marvell、Nvidia、Corigine、Red Hat、Huawei，排名如下：



　　什么是开源社区？开源社区又称开放源代码社区，是一个由开发者，用户和社区成员组成的社群，致力于开发和维护开源软件，其开放性和透明度使任何人都可以自由地查看、复制、使用和修改软件源代码，为开发人员、用户和组织提供了一种相互支持和协作的方式。 　　社区化开发强调各个企业和个人在开发过程中共享代码和资源，芯启源采用此种方式，将DPU软件引入到DPDK驱动的开发中，使得芯启源DPU软件得到了全球许多开发者和使用者的广泛支持。 　　这种社区化的开发方式，让产品开发者可以更好地集中精力于核心功能的开发，同时也能够借助社区力量，实现更好的技术积累和资源共享。 　　DPDK开源社区 　　DPDK、OVS和Linux等开源社区是开发网络、云计算和操作系统等众多领域的重要技术平台，其社区贡献可以加速开源技术的发展创新，降低成本，提高可持续性。其中，DPDK开源社区是当前在高速数据处理领域的前沿社区，是用户态网络数据处理性能和吞吐方面的权威。DPDK (Data Plane Development Kit) 是一个用于加速数据平面软件包处理的工具包，它的基础技术是以CPU为中心的快速数据包处理，适合云计算平台、网络功能虚拟化和软件定义网络等领域的使用。 　　对于个人、企业和组织来说，参与DPDK开源项目可以通过向其贡献新功能、修复错误和提出有价值的想法以改善软件模块，同时也受益于DPDK的高效性和灵活性，可实现更快地转换、更高的速度和更低的延迟等优点。 　　芯启源DPU随着技术的不断进步和应用场景的不断拓展，大量的企业和开发者面临着数据处理和网络传输方面的巨大挑战，为了解决这些问题，DPU应运而生。DPU（Data Processing Unit）作为一种面向先进计算，以提升基础数据任务效能为核心的可编程专用处理器，可卸载网络、存储、安全等业务对CPU的需求，解决了高带宽、低延迟、数据密集的计算场景的算力困境。 　　芯启源DPU的成功离不开社区化开发方式的支持，众多企业和个人通过社区共同参与到开发过程中，共享资源和代码，共同推动了产品的改进和优化。在DPDK 22.11 年终版本中，芯启源提交了完整的DPU RTE_FLOW卸载方案，这使得芯启源DPU成为国内目前唯一一款被DPDK原生版本支持流表卸载的同类产品。同时，芯启源在DPDK社区2022年度代码贡献率在中国所有科技公司中名列第一，展现了深厚的技术功力。 　　二、DPDK 技术简介 　　2.1 软件架构 　　DPDK 的组成架构如下图所示，相关技术原理概述如下：

　　图中，在最底部的内核态（Linux Kernel）DPDK 有两个模块：KNI 与 IGB_UIO。其中，KNI 提供给用户一个使用 Linux 内核态的协议栈，以及传统的Linux 网络工具（如ethtool, ifconfig）。IGB_UIO（igb_uio.ko 和 kni.ko. IGB_UIO）则借助了 UIO 技术，在初始化过程中将网卡硬件寄存器映射到用户态。 　　如图所示，DPDK 的上层用户态由很多库组成，主要包括核心部件库（Core Libraries）、平台相关模块(Platform)、网卡轮询模式驱动模块（PMD-Natives&Virtual）、QoS 库、报文转发分类算法（Classify）等几大类，用户应用程序可以使用这些库进行二次开发，下面分别简要介绍。 　　核心部件库 　　该模块构成的运行环境是建立在 Linux 上，通过环境抽象层(EAL)的运行环境进行初始化，包括：HugePage 内存分配、内存/缓冲区/队列分配与无锁操作、CPU 亲和性绑定等；其次，EAL 实现了对操作系统内核与底层网卡 I/O 操作的屏蔽（I/O 旁路了内核及其协议栈），为 DPDK 应用程序提供了一组调用接口，通过 UIO 或 VFIO 技术将 PCI 设备地址映射到用户空间，方便了应用程序调用，避免了网络协议栈和内核切换造成的处理延迟。另外，核心部件还包括创建适合报文处理的内存池、缓冲区分配管理、内存拷贝、以及定时器、环形缓冲区管理等。 　　平台相关模块 　　其内部模块主要包括 KNI、能耗管理以及 IVSHMEM 接口。其中，KNI 模块主要通过 kni.ko 模块将数据报文从用户态传递给内核态协议栈处理，以便用户进程使用传统的 socket 接口对相关报文进行处理；能耗管理则提供了一些API，应用程序可以根据收包速率动态调整处理器频率或进入处理器的不同休眠状态；另外，IVSHMEM 模块提供了虚拟机与虚拟机之间，或者虚拟机与主机之间的零拷贝共享内存机制，当 DPDK 程序运行时，IVSHMEM 模块会调用核心部件库 API，把几个 HugePage 映射为一个 IVSHMEM 设备池，并通过参数传递给 QEMU，这样，就实现了虚拟机之间的零拷贝内存共享。 　　轮询模式驱动模块 　　PMD 相关 API 实现了在轮询方式下进行网卡报文收发，避免了常规报文处理方法中因采用中断方式造成的响应延迟，极大提升了网卡收发性能。此外，该模块还同时支持物理和虚拟化两种网络接口，从仅仅支持 Intel 网卡，发展到支持 Cisco、Broadcom、Mellanox、Chelsio 等整个行业生态系统,以及基于 KVM、VMWARE、 XEN 等虚拟化网络接口的支持。 　　DPDK 还定义了大量 API 来抽象数据平面的转发应用，如 ACL、QoS、流分类和负载均衡等。并且，除以太网接口外，DPDK 还在定义用于加解密的软硬件加速接口（Extensions）。 　　2.2 巨页技术 　　处理器的内存管理包含两个概念：物理内存和虚拟内存。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 以后的版本，应用软件才可以使用大页表功能，具体的介绍可以参见 Linux 的大页表文件系统（hugetlbfs）特性。 　　DPDK 则利用大页技术，所有的内存都是从 HugePage 里分配，实现对内存池(mempool) 的管理，并预先分配好同样大小的 mbuf，供每一个数据包使用。 　　2.3 轮询技术 　　传统网卡的报文接收/发送过程中，网卡硬件收到网络报文，或发送完网络报文后，需要发送中断到 CPU，通知应用软件有网络报文需要处理。在 x86 处理器上，一次中断处理需要将处理器的状态寄存器保存到堆栈，并运行中断服务程序，最后再将保存的状态寄存器信息从堆栈中恢复。整个过程需要至少 300 个处理器时钟周期。对于高性能网络处理应用，频繁的中断处理开销极大降低了网络应用程序的性能。 　　为了减少中断处理开销，DPDK 使用了轮询技术来处理网络报文。网卡收到报文后，直接将报文保存到处理器 cache 中（有 DDIO（Direct Data I/O）技术的情况下），或者保存到内存中（没有 DDIO 技术的情况下），并设置报文到达的标志位。应用软件则周期性地轮询报文到达的标志位，检测是否有新报文需要处理。整个过程中完全没有中断处理过程，因此应用程序的网络报文处理能力得以极大提升。 　　2.4 CPU 亲和技术 　　现代操作系统都是基于分时调用方式来实现任务调度，多个进程或线程在多核处理器的某一个核上不断地交替执行。每次切换过程，都需要将处理器的状态寄存器保存在堆栈中， 并恢复当前进程的状态信息，这对系统其实是一种处理开销。将一个线程固定一个核上运行， 可以消除切换带来的额外开销。另外将进程或者线程迁移到多核处理器的其它核上进行运行时，处理器缓存中的数据也需要进行清除，导致处理器缓存的利用效果降低。 　　CPU 亲和技术，就是将某个进程或者线程绑定到特定的一个或者多个核上执行，而不被迁移到其它核上运行，这样就保证了专用程序的性能。 　　DPDK 使用了 Linux pthread 库，在系统中把相应的线程和 CPU 进行亲和性绑定, 然后相应的线程尽可能使用独立的资源进行相关的数据处理。 　　2.5DPDK性能影响因素 　　硬件结构的影响 　　DPDK 具有广泛的平台适应性，可以运行在整个 x86 平台，从主流服务器平台（从高性能或者高能效产品系列），到桌面或者嵌入式平台，也可以运行于基于 Power 或者其他架构的运算平台。图展示了一个通用双路服务器的内部架构，它包含了 2 个中央处理器，2 个分离的内存控制单来连接系统内存，芯片组会扩展出大量高速的 PCIe 2.0/3.0 接口，用于连接外设，如 10Gbps 或者 25Gbps 网卡外设。

　　OS 版本及其内核的影响 　　不同的 Linux OS 发行版使用的 Linux 内核版本不一样，配置的 Linux OS 服务也不一样。这些差异都会导致应用程序在网络报文处理能力上有所差别。 　　由于 Linux 内核还在不断演进，Linux 的发行版也数量众多，本文无法提供最佳 Linux 内核版本和配置，而只能给出部分参考建议，如：关闭部分 OS 服务。在后续章节，我们选取了目前比较流行的 Linux 发行版进行了测试，并给出测试结果。从测试结果中显示，同样的硬件配置环境下，不同的 Linux 发行版在小包的处理能力上存在差异。 　　关闭 OS 部分服务 　　在 10G 端口上 64Byte 报文的线速到达率为 14.88Mpps，如果实现零丢包的线速处理，每个报文的平均处理速度应该小于 1/14.48Mpps=67us，DPDK 应用的网卡收发包队列长度缺省配置为 128，网卡队列填充满的时间是 128*67=8579us。也就是说，DPDK 的业务进程，如果被操作系统中断超过 8579us，就会导致网卡收发报的队列被充满，无法接收新的报文，从而导致丢包。而操作系统的中断服务程序、后台服务程序、以及任务调度程序都会导致 DPDK 的应用程序被打断。 　　在 NFV 应用场景下，Host 机器上和 Guest 机器上都运行着操作系统，由此带来了两级的操作任务调度。DPDK 应用程序（NFV 中的 VNF）均运行在虚拟机上，操作系统带来的影响会更加明显。 　　为了实现 DPDK 应用程序的零丢包，需要对操作系统进行适当的配置，减少操作系统的对 DPDK 应用程序的干扰。操作系统配置的总体思路是：将运行 DPDK 应用运行的处理器核进行隔离，减少干扰；停用不需要的后台服务程序。将不需要的中断，转移到其它处理器核上处理；对于不能转移的中断，减少中断的次数。 　　OS 调整示例 　　下面以 CentOS 7 为例，说明具体的调整方法。绝大部分的操作需要同时在 Host 操作系统和 Guest 操作系统同时应用。 　　1) 对 DPDK 应用使用处理器核进行隔离修改 Linux 的 OS 的 GRUB 参数，设置 isolCPUs=16-23,40-47 　　2) 打开运行有 DPDK 进程的处理器核上的 nohz_full。nohz_full 可以减少内核的周期性时钟中断的次数。修改 Linux 的 OS 的 GRUB 参数，设置 nohz_full=16-23,40-47 　　3) 关闭 NMI 监控功能，减少 NMI 中断对 DPDK 任务的干扰。修改 Linux 的 OS 的 GRUB 参数，设置 nmi_watchdog=0 　　4) 关闭 SELinux 功能修改 Linux 的 OS 的 GRUB 参数，设置 selinux=0 　　5) 关闭处理器的 P 状态调整和 softlockup 功能。将处理器锁定在固定的频率运行，减少处理器在不同的 P 状态切换带来的处理时延。修改 Linux 的 OS 的 GRUB 参数，设置 intel_pstate=disable nosoftlockup 　　6) 关闭图形显示，减少 GUI 应用的干扰调用命令 systemctl set-default multi-user.target7) 关闭操作系统的中断调度程序调用命令 systemctl disable irqbalance.service8) 关闭操作系统的审计服务调用命令 systemctl disable auditd.service9) 关闭蓝牙服务调用命令 systemctl disable bluetooth.service10) 关闭 KVM 的内存页合并服务调用命令 systemctl disable ksm.service 调用命令 systemctl disable ksmtuned.service11) 对于 KVM 虚拟的 vCPU 和物理 CPU 进行绑定使用 QEMU monitor vCPU 对应的线程号，使用 taskset 命令进行绑定。 　　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 表项，这可以减少内存地址转换的开销。 　　内存多通道的使用 　　现代的内存控制器都支持内存多通道，比如 Intel 的 E5-2600V3 系列处理器，能支持 4 个通道，可以同时读和取数据。依赖于内存控制器及其配置，内存分布在这些通道上。每一个通道都有一个带宽上限，如果所有的内存访问都只发生在第一个通道上，这将成为一个潜在的性能瓶颈。 　　因此，DPDK 的 mempool 库缺省是把所有的对象分配在不同的内存通道上，保证了在系统极端情况下需要大量内存访问时，尽可能地将内存访问任务均匀平滑。 　　内存拷贝 　　很多 libc 的 API 都没有考虑性能，因此，不要在高性能数据平面上用 libc 提供的 API，比如，memcpy()或 strcpy()。虽然 DPDK 也用了很多 libc 的 API，但均只是在软件配置方面用于方便程序移植和开发。 　　DPDK 提供了一个优化版本的 rte_memcpy() API，它充分利用了 Intel 的 SIMD 指令集，也考虑了数据的对齐特性和 cache 操作友好性。 　　内存分配 　　在某些情况下，应用程序使用 libc 提供的动态内存分配机制是必要的，如 malloc()函数，它是一种灵活的内存分配和释放方式。但是，因为管理零散的堆内存代价昂贵，并且这种内存分配器对于并行的请求分配性能不佳，所以不建议在数据平面处理上使用类似 malloc()的函数进行内存分配。 　　在有动态分配的需求下，建议使用 DPDK 提供的 rte_malloc() API，该 API 可以在后台保证从本 NUMA 节点内存的 HugePage 里分配内存，并实现 cache line 对齐以及无锁方式访问对象等功能。 　　NUMA 考虑 　　NUMA（Non Uniform Memory Access Architecture）与 SMP（Symmetric Multi Processing）是两种典型的处理器对内存的访问架构。随着处理器进入多核时代，对于内存吞吐量和延迟性能有了更高的要求，NUMA 架构已广泛用于最新的英特尔处理器中，为每个处理器提供分离的内存和内存控制器，以避免 SMP 架构中多个处理器同时访问同一个存储器产生的性能损失。 　　在双路服务器平台上，NUMA 架构存在本地内存与远端内存的差异。本地和远端是个相对概念，是指内存相对于具体运行程序的处理器而言，如图所示。

　　在 NUMA 体系架构中，CPU 进行内存访问时，本地内存的要比访问远端内存更快。因为访问远端内存时，需要跨越 QPI 总线，在应用软件设计中应该尽量避免。在高速报文处理中，这个访问延迟会大幅降低系统性能。尤其是传统嵌入式软件向服务器平台迁移时，需要特别。 　　DPDK 提供了一套在指定 NUMA 节点上创建 memzone、ring, rte_malloc 以及 mempool 的 API，可以避免远端内存访问这类问题。在一个 NUMA 节点端，对于内存变量进行读取不会存在性能问题，因为该变量会在 CPU cache 里。但对于跨 NUMA 架构的内存变量读取，会存在性能问题，可以采取复制一份该变量的副本到本地节点（内存）的方法来提高性能。 　　CPU 核间无锁通信 　　如果想建立一个基于消息传递的核间通信机制，可以使用 DPDK ring API，它是一个无锁的 ring 实现。该 ring 机制支持批量和突发访问，即使同时读取几个对象，也只需要一个昂贵的原子操作，批量访问可以极大地改善性能。 　　设置正确的目标 CPU 类型 　　DPDK 支持 CPU 微架构级别的优化，可以通过修改 DPDK 配置文件中的 CONFIG_RTE_MACHINE 参数来定义。优化的程度根据随编译器的能力而不同，通常建议采用最新的编译器进行编译。 　　如果编译器的版本不支持该款 CPU 的特性，比如 Intel AVX 指令，那么它在编译时只会选用自己支持的指令集，这可能导致编译 后生成的 DPDK 应用的性能下降。 　　三、Hugepage配置 　　DPDK中，如果有多个核可能需要同时访问一个网卡，那DPDK中会为每个核准备一个单独的接收队列/发送队列，这样避免了竞争，也避免了cache一致性问题。 　　一般的常规页大小为4K字节，使用大页时页大小设置为2M或1G字节。修改方式如下： 　　Bashrc文件内添加： 　　非NUMA系统 　　预留了1024个2M大页，即2GB内存。 　　NUMA系统 　　上述命令为每个节点各预留了1024个2M大页，即4GB内存。 　　/etc/fstab内添加 　　3.1多线程配置 　　DPDK线程基于pthread接口创建，属于抢占式线程模型，受内核调度支配。通过在多核设备上创建多个线程，每个线程绑定到单独的核上，减少线程调度的开销，以提高性能。控制线程一般绑定到MASTER核上，接受用户配置，并传递配置参数给数据线程等；数据线程分布在不同核上处理数据包。 　　DPDK中初始化及执行任务分发示例如下图所示：

　　lcore初始化及执行任务分发，上图中一共使用了三个cpu核，master core负责进行任务初始化和分发，两个lcore执行任务。 　　3.2转发模型 　　DPDK转发框架分为run tocompletion模型和pipeline模型，对比图如下：

　　DPDK转发模型对比，DPDK run to completion模型中每个报文的生命周期只能在一个线程中出现，每个物理核都负责处理整个报文的生命周期从RX到TX。 　　DPDK pipeline模型中不同的工作交给不同的模块，每一个模块只单独处理特定的事务，各模块之间有输入输出，通过这些输入输出连接起来，完成复杂的网络功能. 　　3.3内存管理 　　DPDK将内存封装在Mbuf结构体内，Mbuf主要用来封装网络帧缓存，所有的应用使用Mbuf结构来传输网络帧。对网络帧封装和处理时，将网络帧数据和帧本身存放在固定大小的同一段缓存中，网络帧数据的一部分内容由DPDK的网卡驱动写入，结构如下图： 　　单帧Mbuf结构 　　head room用来存储和系统中其他实体交互的信息，如控制信息、帧内容、事件等。Head room长度由RTE_PKTMBUF_HEADROOM定义，默认为128. 　　Rte_mbuf结构对象存放在内存池中，内存池使用环形缓存区来保存空闲对象，逻辑结构如下图所示：

　　内存池双环形缓存区结构,当一个网络帧被网卡接收时，DPDK网卡驱动将其存储在一个高效的环形缓冲区中，同时Mbuf的环形缓存区中创建了一个Mbuf对象。Mbuf对象被创建好后，网卡驱动根据分析出的帧信息将其初始化，并将其和实际帧对象逻辑相连，对网络帧的分析处理都集中在Mbuf，仅在必要的时候访问实际网络帧。 　　四、性能优化 　　4.1收发包流程概述 　　DPDK中普遍采用纯轮询模式进行数据包收发，所有的收发包有关的中断在物理端口初始化的时候都会关闭。物理端口上的每一个收包队列，都会有一个对应的由收包描述符组成的软件队列来进行硬件和软件的交互。 　　DPDK驱动程序负责初始化好每一个收包描述符，其中包含把包缓冲内存块的物理地址填充到收包描述符对应的位置，并把对应的收包成功标志复位，通知网卡硬件把收到的包进行填充。网卡硬件将收到的包一一填充到对应的收包描述符表示的缓冲内存块中，将必要信息填充到收包描述符内，标记好收包成功标志。若一个缓冲区内存块大小不够存放一个完整数据包时，可能需要多个收包描述符来处理一个包。 　　针对每一个收包队列，DPDK都会有一个对应的软件线程负责轮询其中的收包描述符收包成功的标志位。当发现一个收包描述符的收包成功标志被硬件置位了，意味着有包进入网卡并且已经存储到描述符对应的缓冲区内存块中。驱动程序将解析相应的收包描述符，填充对应缓冲内存块头部，将收包缓冲内存块存放到收包函数提供的数组中，同时分配好一个新的缓冲内存块给这个描述符，以便下一次收包。 　　针对每一个发包队列，DPDK都有一个对应的软件线程负责设置需要发送出去的包，DPDK驱动程序负责提取发包缓冲内存块的有效信息，根据内存缓存块中包的内容来负责初始化好每一个发包描述符，驱动程序将每个包翻译为一个或者多个发包描述符内能够理解的内容，写入发包描述符。当驱动程序设置好相应的发包描述符，硬件就开始依据发包描述符内容来发包，驱动程序通过发包描述符内的RS发送状态位来决定发包是否结束以及对发包描述符和内存缓冲块进行回收。发包轮询就是轮询发包结束的硬件标志位，DPDK驱动程序会在发包线程内不断查询发包是否结束，网卡根据RS以写回方式通知发包结束。 　　4.2Burst收发包 　　Burst为一次完成多个数据包的收发，通过把收发包复杂的处理过程进行分解，打散成不同的相对较小的处理阶段，把相邻数据访问、相似的数据运算集中处理，尽可能减少对内存或者低一级的处理器缓存的访问次数。网卡收发包描述符一般为16字节或32字节，处理器缓存基本单位为64字节，可以存放2个或4个描述符，处理器预期机制会每次存取相邻多个缓存，若一次处理4个缓存单，则可以更新16个描述符，Burst就可以设置为16.目前常用的Burst为32。 　　4.3平台优化配置 　　硬件： 　　PCIe Gen3 x 8,x16。 　　网卡多队列收发包，支持收包RSS时分发进多个队列。 　　软件： 　　关闭CPU以及设备的省电模式； 　　让内存运行在所支持的最高频率上； 　　内核初始化时设置好大页； 　　增加内核启动参数，预先指定DPDK使用的逻辑核，不被操作系统调度； 　　DPDK参数配置： 　　收包队列长度，即每个收包队列分配的收包描述符个数，反映了在软件驱动程序读取所收到包之前最大的缓存包的能力。太长占用资源，太短容易丢包，默认长度为128. 　　发包队列长度，即每个发包队列分配的发包描述符个数，默认长度为512. 　　收包队列可释放描述符数量阈值，DPDK驱动程序并没有每次收包都更新收包队列尾部索引寄存器，而是在可释放的收包描述符数量达到一个阈值时更新，设置合理，可以减少没有必要的过多收包队列尾部索引寄存器的访问。默认值为32. 　　发包队列可释放描述符数量阈值，通过将回写标记设置在一定间隔的发包描述符上，减少不必要的回写次数，改善性能，默认为32. 　　发包描述符释放阈值，当用来重新配置的发包描述符数量少于阈值时，才会启动描述符和Mbuf释放动作，设置太大释放频繁，影响性能，设置太小可用描述符少，容易丢包，默认值为32。 　　4.4多队列配置 　　DPDK中，通过将网卡的某个接收队列分配给某个核，从该队列中收到的所有报文都应当在该指定的核上处理结束，不同的核操作不同的队列。 　　目前可以通过RSS(接收方扩展)把数据包分配到不同的队列中，该机制根据关键字通过哈希函数计算出哈希值，再有哈希值确定队列。不同的数据包类型具有不同的关键字，例如IPv4 UDP四组（源IP地址、目的IP地址、源端口号、目的端口号）。 　　另一种是Flow Director技术，根据包的字段精确匹配，查找Flow Director表项，将其分配到某个特定队列。 　　DPDK中可以采用RSS来负载均衡，将报文发到多个核上，同时使用Flow Director将控制报文分配到指定的队列上，使用单独的核来处理，如下图所示：