虚拟网络运维----认识DPDK

阳光穿透心脏的1/2处 2023-02-23 05:29 24阅读 0赞

### 文章目录 ###

*   *  认识DPDK
     *   *  简单说明
         *  DPDK最佳实践
         *  寻找性能的天花板
         *  解读数据包处理能力

## 认识DPDK ##

### 简单说明 ###

DPDK全称是DataPlaneDevelopmentKit，从字面解释上看，这是专注于数据面软件开发的套件。本质上，它由一些底层的软件库组成。目前，DPDK使用BSDlicense，绝大多数软件代码都运行在用户态。少量代码运行在内核态，涉及UIO、VFIO以及XenDom0，KNI这类内核模块只能以GPL发布。

DPDK逐渐成为通用多核处理器高性能数据包处理的业界标杆。

ASIC（ApplicationSpecificIntegratedCircuit）是一种应特定用户要求和特定电子系统的需要而设计、制造的集成电路。ASIC的优点是面向特定用户的需求，在批量生产时与通用集成电路相比体积更小、功耗更低、可靠性提高、性能提高、保密性增强、成本降低等。但ASIC的缺点也很明显，它的灵活性和扩展性不够、开发费用高、开发周期长。

网络处理器（NetworkProcesserUnit，NPU）是专门为处理数据包而设计的可编程通用处理器，采用多内核并行处理结构，其常被应用于通信领域的各种任务，比如包处理、协议分析、路由查找、声音/数据的汇聚、防火墙、QoS等。其通用性表现在执行逻辑由运行时加载的软件决定，用户使用专用指令集即微码（microcode）进行开发。

本书介绍DPDK，主要以IA（IntelArchitecture）多核处理器为目标平台。在IA上，网络数据包处理远早于DPDK而存在。从商业版的Windows到开源的Linux操作系统，所有跨主机通信几乎都会涉及网络协议栈以及底层网卡驱动对于数据包的处理。然而，低速网络与高速网络处理对系统的要求完全不一样。

以Linux为例，传统网络设备驱动包处理的动作可以概括如下：

*  数据包到达网卡设备。
 *  网卡设备依据配置进行DMA操作。
 *  网卡发送中断，唤醒处理器。
 *  驱动软件填充读写缓冲区数据结构。
 *  数据报文达到内核协议栈，进行高层处理。
 *  如果最终应用在用户态，数据从内核搬移到用户态。
 *  如果最终应用在内核态，在内核继续进行。

**随着网络接口带宽从千兆向万兆迈进，原先每个报文就会触发一个中断，中断带来的开销变得突出，大量数据到来会触发频繁的中断开销，导致系统无法承受，因此有人在Linux内核中引入了NAPI机制，其策略是系统被中断唤醒后，尽量使用轮询的方式一次处理多个数据包，直到网络再次空闲重新转入中断等待。**

NAPI策略用于高吞吐的场景，效率提升明显。一个二层以太网包经过网络设备驱动的处理后，最终大多要交给用户态的应用，图1-4的典型网络协议层次OSI与TCP/IP模型，是一个基础的网络模型与层次，左侧是OSI定义的7层模型，右侧是TCP/IP的具体实现。

**网络包进入计算机大多需要经过协议处理，在Linux系统中TCP/IP由Linux内核处理。**

网络包进入计算机大多需要经过协议处理，在Linux系统中TCP/IP由Linux内核处理。即使在不需要协议处理的场景下，大多数场景下也需要把包从内核的缓冲区复制到用户缓冲区，系统调用以及数据包复制的开销，会直接影响用户态应用从设备直接获得包的能力。而对于多样的网络功能节点来说，TCP/IP协议栈并不是数据转发节点所必需的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70][]

如何让Linux这样的面向控制面原生设计的操作系统在包处理上减少不必要的开销一直是一大热点。有个著名的高性能网络I/O框架Netmap，它就是采用共享数据包池的方式，减少内核到用户空间的包复制。

NAPI与Netmap两方面的努力其实已经明显改善了传统Linux系统上的包处理能力，那是否还有空间去做得更好呢？作为分时操作系统，Linux要将CPU的执行时间合理地调度给需要运行的任务。相对于公平分时，不可避免的就是适时调度。早些年CPU核数比较少，为了每个任务都得到响应处理，进行充分分时，用效率换响应，是一个理想的策略。现今CPU核数越来越多，性能越来越强，为了追求极端的高性能高效率，分时就不一定总是上佳的策略。以Netmap为例，即便其减少了内核到用户空间的内存复制，但内核驱动的收发包处理和用户态线程依旧由操作系统调度执行，除去任务切换本身的开销，由切换导致的后续cache替换（不同任务内存热点不同），对性能也会产生负面的影响。

### DPDK最佳实践 ###

\*\*轮询，这一点很直接，可避免中断上下文切换的开销。\*\*之前提到Linux也采用该方法改进对大吞吐数据的处理，效果很好。在第7章，我们会详细讨论轮询与中断的权衡。

\*\*用户态驱动，在这种工作方式下，既规避了不必要的内存拷贝又避免了系统调用。一个间接的影响在于，用户态驱动不受限于内核现有的数据格式和行为定义。对mbuf头格式的重定义、对网卡DMA操作的重新优化可以获得更好的性能。而用户态驱动也便于快速地迭代优化，甚至对不同场景进行不同的优化组合。\*\*在第6章中，我们将探讨用户态网卡收发包优化。

\*\*亲和性与独占，DPDK工作在用户态，线程的调度仍然依赖内核。利用线程的CPU亲和绑定的方式，特定任务可以被指定只在某个核上工作。好处是可避免线程在不同核间频繁切换，核间线程切换容易导致因cachemiss和cachewriteback造成的大量性能损失。如果更进一步地限定某些核不参与Linux系统调度，就可能使线程独占该核，保证更多cachehit的同时，也避免了同一个核内的多任务切换开销。\*\*在第3章，我们会再展开讨论。

\*\*降低访存开销，网络数据包处理是一种典型的I/O密集型（I/Obound）工作负载。无论是CPU指令还是DMA，对于内存子系统（Cache+DRAM）都会访问频繁。利用一些已知的高效方法来减少访存的开销能够有效地提升性能。比如利用内存大页能有效降低TLBmiss，比如利用内存多通道的交错访问能有效提高内存访问的有效带宽，再比如利用对于内存非对称性的感知可以避免额外的访存延迟。\*\*而cache更是几乎所有优化的核心地带，这些有意思而且对性能有直接影响的部分，将在第2章进行更细致的介绍。

### 寻找性能的天花板 ###

性能优化不是无止境的，所谓天花板可以认为是理论极限，性能优化能做到的就是无限接近这个理论极限。而理论极限也不是单纬度的，当某个纬度接近极限时，可能在另一个纬度会有其他的发现。我们讨论数据包处理，那首先就看看数据包转发速率是否有天花板。其实包转发的天花板就是理论物理线路上能够传送的最大速率，即线速。那数据包经过网络接口进入内存，会经过I/O总线（例如，PCIebus），I/O总线也有天花板，实际事务传输不可能超过总线最大带宽。

有些天花板可能很难量化，比如在某个特定频率的CPU下每个包所消耗的周期最小能做到多少。对于这样的天花板，可能只能用不断尝试实践的方式，当然不同的方法可能带来不同程度的突破，总的增益越来越少时，就可能是接近天花板的时候。

### 解读数据包处理能力 ###

一般常被提到的有吞吐、延迟、丢包率、抖动等。对于转发，常会以包转发率（pps，每秒包转发率）而不是比特率（bit/s，每秒比特转发率）来衡量转发能力，这跟包在网络中传输的方式有关。

线速（WireSpeed）是线缆中流过的帧理论上支持的最大帧数。

我们用以太网（Ethernet）为例，一般所说的接口带宽，1Gbit/s、10Gbit/s、25Gbit/s、40Gbit/s、100Gbit/s，代表以太接口线路上所能承载的最高传输比特率，其单位是bit/s（bitpersecond，位/秒）。

实际上，不可能每个比特都传输有效数据。以太网每个帧之间会有帧间距（InterPacketGap，IPG），默认帧间距大小为12字节。每个帧还有7个字节的前导（Preamble），和1个字节的帧首定界符（StartFrameDelimiter，SFD）。具体帧格式如图17所示，有效内容主要是以太网的目的地址、源地址、以太网类型、负载。报文尾部是校验码。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1][]

所以，通常意义上的满速带宽能跑有效数据的吞吐可以由如下公式得到理论帧转发率：

![20200705203351616.png][]

而这个**最大理论帧转发率的倒数表示了线速情况下先后两个包到达的时间间隔**。按照这个公式，将不同包长按照特定的速率计算可得到一个以太帧转发率，如表1-1所示。如果仔细观察，**可以发现在相同带宽速率下，包长越小的包，转发率越高，帧间延迟也越小。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2][]

帧转发率满足什么条件才能达到无阻塞转发的理论上限呢？如果我们把处理一个数据包的整个生命周期看做是工厂的生产流水线，那么就要保证在这个流水线上，不能有任何一级流水处理的延迟超过此时间间隔。理解了这一点，对照表1-1，就很容易发现，对任何一个数据包处理流水线来说，越小的数据包，挑战总是越大。这样的红线对任何一个硬件平台，对任何一个在硬件平台上设计整体流水线的设计师来说都是无法逃避并需要积极面对的。

DPDK的出现充分释放了IA平台对包处理的吞吐能力。我们知道，随着吞吐率的上升，中断触发的开销是不能忍受的，DPDK通过一系列软件优化方法（大页利用，cache对齐，线程绑定，NUMA感知，内存通道交叉访问，无锁化数据结构，预取，SIMD指令利用等）利用IA平台硬件特性，提供完整的底层开发支持库。使得单核三层转发可以轻松地突破小包30Mpps，随着CPU封装的核数越来越多，支持的PCIe通道数越来越多，整系统的三层转发吞吐在2路CPU的XeonE52658v3上可以达到300Mpps。这已经是一个相当可观的转发吞吐能力了。

随着数据面可软化的发生，数据面的设计、开发、验证乃至部署会发生一系列的变化。首先，可以采用通用服务器平台，降低专门硬件设计成本；其次，基于C语言的开发，就程序员数量以及整个生态都要比专门硬件开发更丰富；另外，灵活可编程的数据面部署也给网络功能虚拟化（NFV）带来了可能，更会进一步推进软件定义网络（SDN）的全面展开。

DPDK软件包内有一个最基本的三层转发实例（l3fwd），可用于测试双路服务器整系统的吞吐能力，实验表明可以达到220Gbit/s的数据报文吞吐能力。值得注意的是，除了通过硬件或者软件提升性能之外，如今DPDK整系统报文吞吐能力上限已经不再受限于CPU的核数，当前瓶颈在于PCIe（IO总线）的LANE数。换句话说，系统性能的整体I/O天花板不再是CPU，而是系统所提供的所有PCIeLANE的带宽，能插入多少个高速以太网接口卡。

在这样的性能基础上，网络节点的软化就成为可能。对于网络节点上运转的不同形态的网络功能，一旦软化并适配到一个通用的硬件平台，随之一个自然的诉求可能就是软硬件解耦。解耦正是网络功能虚拟化（NFV）的一个核心思想，而硬件解耦的多个网络功能在单一通用节点上的隔离共生问题，是另一个核心思想虚拟化诠释的。当然这个虚拟化是广义的，在不同层面可以有不同的支撑技术。

应对绝对高吞吐能力的要求，DPDK支持各种I/O的SRIOV接口；应对高性能虚拟主机网络的要求，DPDK支持标准virtio接口；对虚拟化平台的支撑，DPDK从KVM、VMWARE、XEN的hypervisor到容器技术，可谓全平台覆盖。可以说，在如火如荼的网络变革的大背景下，DPDK以强劲的驱动力加速各种虚拟化的网络功能部署到现实的网络节点上。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200705203311889.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200705203338875.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70
[20200705203351616.png]: https://img-blog.csdnimg.cn/20200705203351616.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200705203409800.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1,size_16,color_FFFFFF,t_70