《深入浅出DPDK》读书笔记（十四）：DPDK应用篇（DPDK与网络功能虚拟化：NFV、VNF、IVSHMEM、Virtual BRAS“商业案例”）

本书在前面的各章中介绍了DPDK诞生的背景和基本知识，并从软件系统优化的角度解释如何利用DPDK来提升性能，包括cache优化、并行计算、同步互斥、转发算法等。另外，作者还针对Intel X86平台和主流的高性能网卡，阐述了如何提高PCIe IO的处理性能、网卡性能的优化、流分类与多队列以及如何利用硬件卸载功能来承担部分软件功能。同时，本书还介绍了几种主流的虚拟化技术，以及如何利用DPDK构建高性能的数据通路。相信读者在充分了解这些内容后，一定想知道DPDK可以应用到那些实际的场景。接下来本书会使用3章的篇幅来详细介绍这些具体的应用。

第13章主要介绍DPDK与网络功能虚拟化（NFV）的关系，包括NFV的演进、DPDK优化VNF的方法，最后还给出几个成功的商业案例。

第14章讲解Open vSwitch（OVS）中的DPDK性能加速。读者可以从这部分内容中了解到OVS的数据通路架构，DPDK如何支持OVS及其性能。

第15章讨论DPDK在存储领域的应用，其中详细介绍了一套Intel提供的基于IA平台上的软件加速库和解决存储方案SPDK（Storage Performance Development Kit），包括介绍了如何用DPDK来优化iSCSI target的性能。最后介绍几种基于DPDK的用户态TCP/IP协议栈，包括libUNS、mTCP和OpenFastPath。

由于这几章针对一些特定的应用场景，需要读者掌握相应的专业知识，因此不太适合初次接触DPDK的读者，主要面向具备一定项目开发经验的中高级开发人员。希望通过这些有益的尝试和探索，能够帮助广大的工程开发人员把DPDK的思想结合到自己的实际工作中。

DPDK与网络功能虚拟化

NFV（Network Function Virtualization）即网络功能虚拟化。它的兴起源自于电信运营商，初衷是通过使用英特尔X86等通用服务器硬件平台以及虚拟化技术，来承载基于软件实现的网络功能。作为NFV架构中非常重要的一环，DPDK在高速数据报文处理中有着不可替代作用，大量项目和开发工作围绕着如何利用DPDK提高通用处理器的网络处理性能而展开。在本章中，我们会具体描述DPDK如何加速VNF和加速虚拟交换。

157.网络功能虚拟化

13.1.1起源

2012年10月，包含中国移动在内的全球电信运营商在德国举行SDN峰会。欧美电信运营商联合发起成立了网络功能虚拟化产业联盟（Network Function Virtualization, NFV），并发布了NFV第一份白皮书。该文件结合云计算与SDN发展趋势，提出了如何利用普通的服务器资源进行电信网络设备的研发和采购。此后，ETSI欧洲电信标准化协会下成立了国际标准组织NFV ISG，对互连互通的标准化过程进行规范与加速，定义了最终目标是以软件方式虚拟化IT资源，将重要的网络功能实现虚拟化部署。白皮书内容请详见：http://portal.etsi.org/NFV/NFV_White_Paper.pdf[Ref13-1]。

众所周知，传统的电信运营商的网络极其复杂，如图13-1所示，设备类型繁多。而网络功能虚拟化旨在改变网络架构师的工作方式，通过标准的虚拟化技术将许多网络设备迁移到符合工业标准的大容量服务器、交换机和存储上。在一个标准服务器上，软件定义的网络功能可以随意在不同的网络位置之间创建、迁移、删除，无需改变设备的物理部署。

图13-1 未来网络功能虚拟化部署设想

我们在目前的网络架构中，可以经常遇见下面一些网络设备：

❑Message Router：消息路由器。
❑CDN：内容传送网络，加速缓冲内容（如视频）业务。
❑Session Boarder Controller：会话边界控制器，用于电话或无线信令控制。
❑WAN Accerleration：广域网加速。
❑DPI：深度报文检测。
❑Firewall：防火墙，阻断恶意攻击。
❑Carrier-Grade NAT：运营商级网络地址转换。
❑Tester/QoE Monitor：测试与网络质量监控。
❑BRAS：宽带接入设备服务。
❑PE Router：运营商路由器。
❑SGSN/GGSN：移动核心网关，支撑数据业务。
❑Radio/Fixed Access Network：无线或者有线接入网络。

过去20年无线和固网传输技术的飞速发展，使上述设备类型一直不断增加。每个设备都是独立复杂的系统，这些系统通常采用的是大量的专用硬件设备。当新增网络服务（比如智能业务）出现时，运营商还必须增加新的系统，再次堆砌专有硬件设备，并且为这些设备提供必需的存放空间以及电力供应。而且，传统专有硬件设备的集成和操作复杂性高，需要较强的专业设计能力，因此大型的电信设备制造商不得不配置大量的技术人力资源，研发成本极高，因此导致网络设备成本昂贵。另外，专有的硬件设备还面临产品开发周期限制，例如芯片设计需要不断的经历规划-设计开发-整合-部署的过程。从芯片规划到网络部署，跨越整个产业链的协同合作，因此是个漫长的周期过程，运营商的网络扩展建设也变得越来越困难。近年来，随着技术和服务加速创新的需求，硬件设备的可使用生命周期变得越来越短，这影响了新的电信网络业务的运营收益，也限制了在一个越来越依靠网络连通世界的新业务格局下的技术创新。

在软件与芯片技术飞速发展的大背景下，能否抛弃专有硬件平台，转而使用成熟实惠的服务器，结合存储与交换技术，来构建基于通用平台的未来网络呢？

这一思路已经得到了业界的肯定。NFV第1版白皮书明确提出，随着云计算技术的不断成熟发展，从软件角度，大量的针对网络功能虚拟化的基础软件不断推出，例如虚拟化软件KVM、DPDK、Linux NAPI以及运行服务器上的OVS虚拟交换网络等；从硬件角度，在摩尔定律推动下Intel服务器多核平台性能不断提高，具有TCP卸载与负载均衡功能的高速网卡迅猛发展。从趋势上看，软硬件的协同高速演进，使得NFV的行业趋势在技术可行性上成为可能。

158.发展

伴随着NFV联盟进一步壮大，2013年10月在德国，ETSI就NFV的进展又发布了一份白皮书，中国电信与中国联通正式加入NFV组织。新的白皮书总结了NFV的使用场景、需求、总体框架以及可行性范例，强调了开源软件和标准化，对运营支撑系统的影响，对接口标准化与多厂商兼容性的支持实现。

图13-2展示了ETSI设计的NFV架构图，它定义哪些模块可以被供应商重新实现以提供兼容未来NFV的产品。详见内容见：https://portal.etsi.org/nfv/nfv_white_paper2.pdf[Ref13-2]。

图13-2 NFV的基本架构

NFV架构框架包括以下主要模块：

❑NFVI（网络功能虚拟化基础设施），它提供了支持网络虚拟功能执行所需的虚拟化资源，包括符合COTS（Commercial-Off-The-Shelf）开放式标准定义的硬件，必要的硬件加速器，可以虚拟和抽象底层硬件的软件层。
❑VNF（虚拟网络功能），是一个软件实现的网络功能，能够运行在NFVI框架之上。它可以和一个单元管理系统（Element Managmet System, EMS）工作，是适用于特定的功能。VNF类似我们今天的网络节点，纯软件的实现可以帮助网络设备脱离对硬件依赖。更加通俗的理解是，NFV是一种新型的网络设备部署方式，VNF则是其中某个被实例化的虚拟网络设备或节点。
❑NFV M&O（NFV管理与编排），主要负责所有与NFV相关的硬件和软件资源的管理与编排，覆盖整个虚拟网络基础设施的业务流程和生命周期管理。NFV M&O专注于在NFV架构下虚拟化相关的管理任务，也负责与外部的场景进行交互，包括运营支撑系统（Operation Support System, OSS）和业务支撑系统（Buniess Support System, BSS），使NFV能够顺利集成到一个已存在的网络管理系统。

由于NFV技术本身处在初期，涉及各个厂商设备互联，是个非常宏大的主题，依赖很多关键开源软件技术，所以行业标准是在不断演进和发展中。

在此之前的传统模式下，运营商在进行采购时，通常要求设备制造商提供整系统解决方案，集成并且完成交付。在NFV以及SDN的技术趋势下，越来越多的运营商倾向使用云计算数据中心采购模式，即将服务器、操作系统、虚拟软件技术以及虚拟网络设备方案、NFV控制器拆分并单独采购。这是电信系统设备的设计与运营的全新模式，涉及大量工作。

从商业角度，这种全新模式给传统服务器厂商带来了巨大的商业机会，原先的网络设备提供商，传统上是提供整系统方案（包含硬件平台与软件），转化成以软件设计交付产品与服务。举例说，原先的路由器和防火墙设备商，以后需要提供虚拟路由器（vRouter）、虚拟防火墙技术（vFirewall）。这类设备被抽象，称为VNF（Virtual Network Function，虚拟网络功能）。网络设备商可以提供通用硬件服务器平台，和传统服务器制造商竞争，作为VNF运行的基础平台，这是电信运营商定义的产业模型。

在运行模式与设备交付上，这种全新模式对现有网络设备商是个挑战，同时给创新者带来新的市场机会，VNF将是以软件为中心的产品，不再需要大量高复杂度的硬件特殊平台，准入门槛大幅降低。

DPDK主要关注在数据平面的典型场景中，在通用服务器上运行多个或者多种VNF, VNF作为虚拟网络功能（如前述的防火墙或者路由器），要能处理高速数据。因此，基于DPDK的加速极其重要。VNF运行在虚拟化环境下，数据报文会先进入主机，然后被转入虚机，要求高速的虚拟接口与交换技术，DPDK也可以进行优化，后文会重点描述。

例如，在图13-3中，我们看到在网络实际部署中，如果企业路由器需要20Gbit/s的处理能力，借助专用芯片加速，现有路由器很容易实现这样的性能指标。但在NFV框架下，如果虚拟路由器运行在虚机中，依靠现有的虚拟化技术在单个虚机上实现20Gbit/s小包数据传输是有技术挑战的。因此在部署上，我们可以通过水平扩展网络设计，比如同时部署4个虚拟路由器，每个虚拟路由器只需要提供5Gbit/s的处理能力，就能有效避免纯软件与软硬件融合系统之间的性能差距。此处只是一个简单的示例，不代表真实网络部署场景，虚拟路由器的实例可以跨域多个服务器，甚至是跨越数据中心按需部署。

图13-3 虚拟路由器的水平扩展部署

159.OPNFV与DPDK

在运营商的大力推动下，新技术投资蕴含巨大商业利益，NFV产业联盟迅速壮大。从社会分工角度，运营商只负责网络建设、规划、运营与服务，不负责电信系统的研发、设计和生产。而专业的电信设备商需要满足NFV技术规范，改造或者重新设计电信系统设备，来完成网络的变革。

一个全新的名为OPNFV的开源组织诞生于2014年，这是建立在Linux Foundation领导下，金牌成员包括了Intel、中国移动、HP、华为、中兴、AT&T、思科、DELL、爱立信、IBM、Nokia、EMC、Vodofone、NEC、Docomo、Juniper、Brocade，银牌会员更多，众多行业重量级厂商和新创厂商纷纷加入，详细名单可以参见www.opnfv.org。

从上面长长的名单可以看出，这个组织基本囊括了电信与传统IT领域的主要厂商，涉及从芯片设计、操作系统、服务器，到设备研发、存储、运维的全产业链的规模。OPNFV建立之初，就希望最大限度地利用现有开源软件技术，启动了众多的项目，比如OpenDaylight、OpenStack、Ceph存储、KVM、Open vSwitch以及Linux技术，这些大多数也已成为支撑云计算发展的主流开源软件。

目前，OPNFV的主要项目展示在https://wiki.opnfv.org/。作为通用处理器平台上的数据面软件，DPDK在其中扮演了非常重要的角色，很多NFV的开源项目直接或间接用到DPDK，包括DPACC（数据面加速）、Open vSwtich for NFV、OpenContrail Virtual Networking for OPNFV、NFV Hypervisor/KVM、Software FastPath Service Quality Metrics、Service Function Chaining等项目。这些与DPDK有关的项目，在Collaboartive Development的7个项目中占了5个，显而易见DPDK作为基础软件的重要性。我们预计随着OPNFV的发展日新月异，会不断有新的项目加入。在中国市场，华为和中兴大量投入和参与相关的开源项目的工作，贡献了大量的代码，并希望藉此蜕变成新的行业领军者，引领标准定义和早期开放，占据先发优势。

为了更好地支持OPNFV对数据面的需求，DPDK除了着重在基础运行环境与轮询驱动模块方向进行开发，还提出了所谓DPDK-AE（DPDK加速引擎）的技术框架，读者可以在本书第1章中看到相关的DPDK的软件框架图。这里主要介绍下面一些关键的技术，帮助读者了解DPDK如何推动OPNFV技术的普及与成熟。

除了网络数据转发之外，DPDK近期还推出了一些针对特定领域的数据处理功能，包括CryptoDev API、Pattern Matching API和Compression API。目的是通过这些接口，DPDK基础库可作为统一的硬件资源使用入口，给上层的应用提供多样的高性能数据处理功能。目前这部分工作还处于早期设计开发阶段，需要一段时间酝酿，在得到相关的生态系统的广泛接受之后，这个接口规范才能成熟。详见[Ref13-4]。

❑CryptoDev API：主要用于数据块加解密领域，API可以下挂基于Intel架构的AES-NI的指令集，也可以下挂使用基于Intel QuickAssit的加速插卡。由于大量网络数据传输需要密文传送进行，为了防止信息泄露，数据面需要涉及大量的加解密操作，比如SSL、IPSec、SRTP，又如WLAN以及LTE、WCDMA的无线系统等。在结合DPDK与QAT后，AES-NI可以构建高效的4～7层的网络处理系统，比如HTTPS加速，与负载均衡软件。另外，除了对称的加密机制，不对称的密钥运算也是消耗CPU运算资源的关键点，这也是CryptoDev所关注的重点，通过提高相应的接口，可以快速调用相关的加速单元进行处理。
❑Pattern Matching API：广泛应用于字符的查找匹配，基于正则表达式的查找匹配，这项技术被广泛用于网络安全设备中，例如深度报文检测、防火墙、病毒检测等。Intel在2015年10月开源了一个最新的软件库Hyperscan，这个项目被放在http://www.01.org/hyperscan。这部分API重点关注如何在DPDK层面直接访问和有效利用Hyperscan的软件能力。目前这个软件库还在定义和开发中。
❑Compression API：用于数据的压缩与解压缩领域，这项技术目前被计算机系统广泛应用，在网络传送与存储中比比皆是。DPDK定义了一套APIs支持快速压缩与解压缩，这个项目已经得到DPDK社区的普遍关注与支持。

这里我们多花一些篇幅介绍一些其他的数据面加速技术，除了DPDK, Open Data Plane（ODP）也是比较受关注的技术。ODP产生于ARM的生态系统，诞生时间比DPDK晚，目前ODP兼容DPDK技术，侧重于提供软件编程接口直接调用硬件加速功能。而DPDK起初产生于Intel，侧重基于通用服务器的软件优化，在OPNFV成立前已经成为行业内最知名的技术，并在2015年开始提供针对硬件加速技术的接口调用API，从DPDK R2.2开始对ARM进行支持，能兼容ODP的生态系统。两者从技术角度大同小异，作为技术人员，我们的关注重点应是虚拟化以及硬件资源的灵活使用和可编程性。

NFV的部署

160.NFV的部署

作为多核的通用处理器的代表，Intel架构是现有服务器平台的王者，平台稳定且完全开放，基于PCIe的I/O是个开放接口，在需要特殊加速单元时，可灵活删减或者增加，而且整个系统设计思路主体侧重软件功能应用，是目前NFV平台的首要选择。

基于通用处理器进行NFV，所带来的好处主要是硬件资源平台重用与开放，通用的平台可以在网络、计算以及存储的系统中灵活复用，统一采购，这可以保护现有投资。基于专有加速处理单元的NFV解决方案，灵活性不够，性能上由于专有芯片，在部分工作负载上占优。

在NFV已经达成行业共识的今日，到演变成NFV的大量商业化部署与使用，需要时间和经历不同的发展阶段。对于现有的电信网络设备提供商，或者创新创业者如何分阶段加入，值得推敲。HP就针对商业部署，做了如下四个阶段的切割分解，具有一定的普遍性，详细内容大家可以参考HP关于OPNFV的博文（http://community.hpe.com/t5/Telecom-IQ/HP-s-4-Stages-of-NFV/ba-p/6797122#.VkgiIXYrJD9）[Ref13-3]。

1．分解

第一个阶段是网络功能的模块化与软件化，将依赖专用下层硬件的设计进行软件化的修改，达到能够移植到通用服务器上的标准。毋庸置疑，专用下层芯片设计能带来传统软件所不能带来的性能优势，但专用芯片的弊端是没有普适性，容易过时。这个阶段开发者需要借用服务器运算平台的并行与并发能力以及软件优化来解决性能上的顾虑。软件架构的更改，能带来巨大的灵活性，随着Linux和开源技术的发展，有大量可以利用的开源软件作为基础，来构建网络功能应用，并且在集成DPDK的技术后，能有效提高报文吞吐处理能力。这个模式目前在国内的阿里巴巴、百度、腾讯等公司的业务中都得到了很好的验证，很多应用已经上线运行，经受住了实际业务的考验。而且，大型数据中心特别青睐这种通用软件模型，基于DevOps（Development和Operations，是一组过程、方法与系统的统称），可以重用现有的大量服务器设备资源；能动态进行网络功能的定制，基于业务需要的自由变动，这在原先的采购第三方网络设备中是无法短期达到的。

2．虚拟化

电信厂商通过软件将传统网络设备迁移到虚拟机后变成VNF（Virtual Network Function），可以利用虚拟化技术带来部署上的灵活性，根据服务器平台运算资源的密度，动态部署。实际使用者也可以根据实际的需求增加或者减少网络功能（如虚拟防火墙），降低运营和维护的成本，从而保证其在基础设备上的投资效率最大化。从厂商角度，VNF具有强大的移植性，部署多个VNF可以灵活、有效地提升资源密度。这种水平扩展不但能够增加处理器的使用效率，对下层的硬件平台也没有依赖，还可以避免锁死在单个供应商，进退有据。关于VNF虚拟化技术如何选择，我们会在后续章节中详细描述与比较，这里就不多做展开。

3．云化

云计算需要实现动态扩容，按需增加处理能力。运算负荷与能力大量提升同时，网络数据处理量也会大幅增加。当基于虚拟化技术的VNF已经就绪后，还需要支持动态地将网络设备功能迁移的能力，提供弹性的网络数据业务。美国的Amazon公司就提供了Market Place，支持了各种虚拟网络功能，作为选择的配置，企业与个人用户在线自由购买，部署VPN在云计算的环境里，远程地来构建基于云的企业IT网络。

这个特性在电信运营里具有很高的商业价值，提升容量是取得更大收益的基本方式。除了动态部署，VNF与虚拟交换的设计中还需要预先考虑支持自动连接，保证数据在指定的VNF业务链上按照定制的策略流动。目前国际标准化组织也正在定义Service Function Chaining（网络功能服务链）过程中。

4．重构

重构是将虚拟化的资源和VNFs拆分成更小的功能单元，即所谓的微服务。可以想象一下，所有的网络、计算、存储资源和架构都是分布式的，每个网络功能都可拆分为很多基本的功能模块，这些模块被分散在不同的资源池。网络服务只是把这些功能单元组织串联起来。这种模式最大程度允许电信运营商和他们的客户通过不同的微服务模块搭建很多创新的网络功能。

举个简单例子，在传统企业网络里构建一个IT系统，用户需要购买一系列不同的IT网络设备，比如防火墙、路由器、服务器等，这是一个比较复杂的工作。但是，如果企业选择基于云计算的解决方案，企业只需要定义服务器、相应的的软件配置、防火墙、负载平衡和路由与交换需求，云服务提供商（Cloud Service Provider）或者是电信服务提供商（Telco Service Provider）会提供一个完整的基于云的网络。如果这个网络是基于NFV技术构建的，那么所有的网络和IT资源都能通过标准服务器来提供，用户只需要将一系列的VNF与虚拟化的应用软件部署在每台服务器中，这就实现了一个灵活有效的部署模式。我们可以通过编排不同的VNF来实现不同的微服务。比如说，同一台服务器上可以运行了web服务器，邮件服务器，也提供了虚拟防火墙，虚拟路由器等网络服务资源。由于用户可以按照需求定制网络拓扑结构和数据转发策略，并根据实际情况进行动态修改，这允许进入这个网络的数据可以按照网络服务的需要在这个企业网络的内部有效流动。这种改变给我们展示一个全新的产业趋势，企业将与服务提供商一起重新定义未来的基础网络服务。

VNF部署的形态

161.VNF部署的形态

在前面的章节中我们介绍了VNF是NFV的重要组成部分之一。VNF把传统的非虚拟化网络中的功能节点进行虚拟化，例如，3GPP定义的EPC网络中的MME（网络管理实体）、SGW（服务网关）、PGW（PDN网关）等节点，或者数据中心网络中常见的防火墙、路由器、负载均衡器等。这些网络功能提供的服务以及对外接口无论是否有虚拟化，相对用户来说应该是透明的。

VNF在NFV的基本架构（见图13-2）中处于NFVI的上面，当考虑VNF的性能时，需要考虑本身的架构设计，以及NFVI能够提供的硬件资源能力和交互接口。本节在这些方面上给出一些阐述。

VNF可以由运行在多个虚拟机上的不同内部模块组成。例如，一个VNF可以部署在多个虚拟机（VM）上，每个虚拟机分别处理这个VNF中的一个单独模块。当然，一个VNF也可以部署在一个虚拟机上，如图13-4所示。参见[Ref13-5]。

图13-4 VNF与多个虚拟机部署结构

传统的网络功能可能是运行在专有软硬一体化平台上，因此硬件芯片、操作系统、应用程序开发等与在x86平台设备上开发有所不同。虚拟化技术的引入，给VNF的部署带来了好处，同时对VNF的软件设计也带来了挑战，尤其是如何将VNF功能模块化、VNF与VNF之间整合、集成式管理单元等等。目前的设计思路需要从扩展性、可复用性和更快的响应速度等来考虑。为了让VNF可以以更低的成本部署在x86平台上，并方便设备扩容与升级，一般在系统整体架构的设计方面，我们需要考虑如下几点[Ref13-6]：

❑系统资源的分配：需要评估整个VNF或者VNF的子模块的特性，以及它们对处理器、内存、存储、网络的需求等。这样才能合理地分配系统资源给其虚拟机去使用。
❑网卡虚拟化接口的选择：在专有平台上，物理网络接口对网络功能节点而言是独占的。部署NFV后，该物理网络接口通过网络虚拟化层抽象后提供给VNF使用，可以独占，也可以各虚机共享。用户如何选择虚拟网络接口，需要考虑该网络接口的性能、迁移性、维护性以及安全性等。
❑网卡轮询和中断模式的选择：通常，网卡的驱动程序采取中断方式来接收报文，但在处理小包的情况下性能不是很好。这时可以采取前面所述DPDK的轮询方式来接收网络报文，能够提高网络的吞吐量性能。当然，轮询意味着需要100%地占有一个处理器核。在虚拟化后，尽管一台服务器承载的虚拟机个数可以很多，但100%地占有一个处理器核来处理网络报文，是不是合理？其网络吞吐量有没有预计那么高？这也是需要考虑的一个因素。
❑硬件加速功能的考虑：目前市场上已经有一些智能加速卡的产品，如支持部分功能硬件卸载的网卡、定制的FPGA、可加解密/压缩解压缩的Intel的QAT（Quick Assistant Technology）卡甚至智能网卡等。这些硬件把对报文中间处理的逻辑放在加速卡上来做，从而释放CPU的利用率，让服务器可以将更多的计算资源用来处理用户自身的业务。如果采用硬件加速功能，用户则需要综合地使用加速卡对网络报文处理的时延，业务处理性能的提高，以及性价比等，寻找到一个权衡点。
❑QoS（服务质量）的保证：在NFV系统下，一个基于x86的平台可能运行有多个VNF。通用平台上的很多资源是共享的，如最后一级处理器cache（LLC），内存、IO控制器等。但是，每个VNF的特性可能不一样，因此它们对资源的使用率是不同的。这可能会造成VNF之间互相干扰，反而造成性能下降，用户在设计方案时一定要考虑这些因素。

针对上面这些VNF部署中的挑战，目前DPDK基本都有对应的技术方案可供选择。

162.VNF自身特性的评估

在了解VNF的部署形态和挑战之后，我们需要一套有效的设计方法帮助定义具体的VNF功能和性能分析。首先，我们需要对VNF或者其子模块的特性有一个大体的了解。通常主要从两方面去了解：

1）虚拟网络设备本身的特性。比如是计算密集型，内存带宽密集型，还是IO密集型？需要几个处理器核，内存大小，存储/网络吞吐量多少？对实时性、时延有要求吗？
2）设备的可扩展性。VNF的软件架构扩展性如何？如果增加一个处理器核，或增大一些内存，其性能可以提高多少？或者增加一个VNF的虚拟机，性能可以提高多少？

通常，数据平面的VNF设备（vRouter、vCDN等），主要是处理数据报文的接收、修改、转发等，这些都要求密集的内存读写操作，以及网络I/O操作。而控制平面的VNF设备（vBRAS等），它们主要不是处理数据通信的，更多是处理会话管理、路由或认证控制等。与数据平面的VNF设备相比，对每个报文的处理逻辑要复杂点，所以更偏计算密集型。但由于控制平面的报文速率偏低，因此它的整体处理器的利用率并不高。但是，数据信号处理的VNF（vBBU），其有大量的数字处理请求，如快速傅立叶变换的编解码操作，这些设备就是计算密集型，对时延有较高的要求。

如果我们能够清楚地回答这些问题，就可以知道系统的主要瓶颈在哪里？硬件、软件、处理器、内存还是IO外设，或是VNF本身设计（大量的锁冲突），还是NFVI里的宿主机、vSwitch。如果我们了解了主要瓶颈，就可以有针对性地去设计并优化整个系统架构，而不会无谓地浪费资源。

163.性能分析方法论

性能分析方法论有助于了解自身的特性，并对性能优化提出指导性的建议。这里，业界大多数采用从非虚拟化到虚拟法，从上到下、闭循环的方法论。如图13-5所示：

图13-5 性能分析方法

首先，把VNF先部署在非虚拟化环境下。在性能调优之前，我们需要先定义度量指标，想优化哪个方面，网络吞吐率、时延、可扩展性等。在不同的阶段，这些想要优化的度量值可能不一样。定义好度量值之后，就需要知道当前的基准性能值是多少。按照闭循环的方法论，先做一些实验，分析可能存在的瓶颈。通过一些简单实验以确认是否是性能瓶颈或者可以优化的地方，然后找到最优的方法去优化它，并再次做实验，以确保优化有效。最后，回到原点，得到一个新的基准性能值。然后，如此闭循环优化，直到达到一个确定的硬件瓶颈或者既定的优化目标。

在找可能是瓶颈的地方，需要遵照从上到下的原则。先从BIOS配置和操作系统配置开始，对不同类型的VNF，其配置不同可能对性能有很大的影响，比如NUMA架构、大页的分配等。接着，就要从VNF应用程序本身软件架构去分析，比如扩展性良好、查表算法耗时等。最后，可能需要从硬件微架构去确认系统的瓶颈已经到达硬件限制，需要升级硬件或增加硬件才能提高性能。

在非虚拟化下得到最好的性能值以及所需的资源配置，然后把该配置移植到虚拟化环境下，按照相似的方法（从上到下、闭循环的方法）进行性能优化，以尽可能接近在非虚拟化下的性能。只不过在非虚拟化下，需要考虑宿主机的影响，它传递给客户机的IO接口性能（包括主机上的vSwitch）等，以及客户机操作系统自身的配置。

在从非虚拟化到虚拟化，从上到下、闭循环的方法论中，还有需要注意以下几点：

❑每次只修改一个配置或一个地方。
❑每次只专注在一个性能度量值的分析上。
❑尽量用简单的、轻量级的程序来验证是否是瓶颈，以及优化方法。
❑及时保存并记录好所修改的地方和实验数据，以防需要回退。

164.性能优化思路

根据在基于x86通用服务器上大量的开发和性能调试的经验，我们总结出一些常见的主要性能瓶颈，以及在不同的层次上可能采用的优化思路。表13-1所列举的都是一些技术优化点，可以单独或混合采用。我们从底层硬件层面（CPU处理器，内存，网卡等）的选用，到操作系统的优化配置，再到软件自身设计的考虑上给出一些建议。他山之石可以攻玉，供大家参考。

表13-1 系统优化表

VNF的设计

165. VNF虚拟网络接口的选择

目前NFVI提供给虚拟机的网络接口主要有四种方式：IVSHMEM共享内存的PCI设备，半虚拟化virtio设备，SR-IOV的VF透传，以及物理网卡透传，如图13-6所示。

图13-6 网卡虚拟化接口

我们在之前的章节中，已经详细的解释了virtio、SR-IOV的VF透传等技术，这里就不再赘述。

下面从性能、操作性、迁移性和安全性来简要比较Virtio以及SR-IOV VF/PF直通接口的优缺点，给VNF的实现在网络接口的选择提供一些建议。

表13-2 虚拟化接口技术比较

166.IVSHMEM共享内存的PCI设备

IVSHMEM是Cam Macdonell[Ref13-7]提出的概念，基于Qemu的技术实现，用于虚拟机之间或虚拟机和主机之间共享内存的一个机制。它把主机上的一个内存块映射成虚拟机里的一个PCI设备，有三个BAR空间。BAR0是1K字节的MMIO区域，里面是一些寄存器。BAR1是用于配置MSI-X中断，虚拟机之间可以实现中断或非中断模式的通信，虚拟机和主机之间只支持非中断模式的通信。BAR2就是映射出来的共享内存，其大小通过命令行指定，必须是2的次方。

目前，DPDK提供了一个基于IVSHMEM的开发库，继承了虚拟机之间或虚拟机和主机之间的共享内存高效的零拷贝机制。主机上运行一个DPDK程序，它调用API把几个大页映射成一个IVSHMEM设备，并通过参数传递给Qemu。在IVSHMEM设备中有一个元数据文件用来标识自己，以区别于其他的IVSHMEM设备。虚拟机里的DPDK进程通过DPDK的环境抽象层自动地识别该IVSHMEM设备，而无须再次把IVSHMEM设备映射到内存。

图13-7是一个典型的DPDK IVSHMEM使用示例：

如通常的DPDK程序一样，主机上DPDK程序使用大页，在大页中分配两个memory zone: MZ1和MZ2，创建两个元数据文件，传递给Qemu，虚拟机里的DPDK程序就自动地可以使用这两块内存了。

图13-7 一个典型的DPDK IVSHMEM使用示例

目前，IVSHMEM支持的元数据文件个数是32，每一个元数据文件之间可以包含不同的大页，或者相同的大页。虚拟机之间或虚拟机和主机之间共享内存就需要双方都拥有该元数据文件。

下面列出DPDK IVSHMEM库的主要API：

❑rte_ivshmem_metadata_create（const char * name）：创建一个新的元数据文件，name就是用来标识不同的元数据文件。
❑rte_ivshmem_metadata_add_memzone（const struct rte_memzone * mz, const char * md_name）rte_ivshmem_metadata_add_ring（const struct rte_ring * r, const char * md_name）rte_ivshmem_metadata_add_mempool（const struct rte_mempool * mp, const char* md_name）：分别把rte_memzone, rte_ring, rte_mempool放入元数据文件。
❑rte_ivshmem_metadata_cmdline_generate（char *buffer, unsigned size, const char*name）：生成传递给Qemu的命令行参数。

如果考虑采用DPDK IVSHMEM机制作为同一主机上的不同虚拟机之间进行通信的方式，我们还有一些因素需要考虑。

首先是安全因素，IVSHMEM从本质上来说，给主机上的内存开了一个后门，可以让虚拟机访问到。那么，这个虚拟机需要是可信赖的，特别是当多虚拟机之间共享同一内存。另外，如果这个共享的内存出问题了，它会不可避免地影响到主机，以及同它共享的几个虚拟机的运行。其次，IVSHMEM的使用就像多进程间的通信，需要考虑访问的同步性以及线程安全性问题，因此也不建议使用函数指针，因为函数在不同的进程里可能会指在不同的内存地址。最后，还需要考虑共享内存里的内存变量的释放问题，最好谁生成谁释放。

另外memnic也是基于IVSHMEM和DPDK机制实现的一个半虚拟化网卡。更多信息可以参考：http://dpdk.org/browse/memnic/tree/

167.网卡轮询和混合中断轮询模式的选择

如果在自身特性的评估中我们得出VNF自身特性是IO密集型的，并且是全时间段或大多时间段都是这种特性，那么毫无疑问我们应该选择轮询模式，它能够最大限度地获得性能，当然也需要处理器100%地处于繁忙状态一直维持运行在最高的处理器频率上，这也意味着系统一直维持最大能耗。

但如果不是全时间段的IO密集型，是间歇性，一段忙一段闲的情况，那么选择轮询模式可能会浪费更多处理器资源和能耗。在这种场景下，可以选用混合中断轮询模式，如第7章7.1.3节介绍。

168.硬件加速功能的考虑

数据中心服务器已经开始或者正在大量部署10G/25G/40G的高速网卡技术，这是云计算的网络技术升级潮流，意味着普通服务器也需要强大的包处理与协议解析能力。从电信融合IT计算的角度，SDN/NFV的新技术是围绕利用服务器平台来设计网络功能。扩展开来，上述的数据包处理过程中一些单调重复性或者采用特殊硬件可以加快处理速度的功能，如果将其下移到硬件（比如网卡）上完成，作为服务器的对外数据入口，切合了技术发展的大潮，未来还将承担更多的智能化处理功能。从技术创新角度，网卡的硬件卸载技术被提出并逐步应用起来，也符合产品技术创新、设计定位差异化的要求，便于在竞争中胜出，符合商业逻辑与潮流。

如第9章介绍，虽然目前大多数网卡已经支持报文基本功能的硬件卸载能力，但是随着全球网络流量爆发式增长，同时随着网络应用更加多样化和复杂化，对可灵活扩展的卸载解决方案的需求也在不断增加。这些方案专注于加速网络接入控制、监控、深度报文检测、安全处理、流量管理、IPSec和SSL虚拟专用网络以及应用智能化等功能，可以提高处理效率，降低服务器的CPU负载，节约投资和能耗。目前，Intel、Cavium、Tilera、Netronome、Freescale、QLogic等陆续推出基于PCIe或FPGA的智能加速卡产品。如Intel通信芯片组89xx系列，就可以对报文加解密、压缩解压缩加速。

那么，VNF是否可以利用这些智能加速卡来取得进一步的性能提升；我们需要从下面几个因素综合评估：

❑SR-IOV：是否可以被虚拟机独占的，还是可以共享的？
❑报文处理路径：报文卸载到硬件处理后，是否还需要返回到CPU继续处理，或有多次CPU与硬件加速卡的交互，并且和传统的全软件处理比较，其报文处理路径是否有增长，对性能的影响如何？
❑时延：由于宿主机的加入，会导致在虚拟设备上处理报文的时间变长。智能加速卡的引进，能否帮助减少处理报文时延？如果整个报文处理时间增长，其时延是否可以被业务所接受？
❑智能加速卡的性价比、灵活度等。

下面举一个非网卡类型的智能加速卡，看DPDK如何支持这一类型的加速卡，并提高实时处理网络报文性能，同其他报文处理线程合作工作。这个思路对于其他公司或类似的加速卡也有很大的启发意义，我们可以用类似的概念实现硬件卸载和性能提升。

Intel QAT技术[Ref13-13]提供用于提高服务器、网络、存储和基于云的部署的性能和效率的安全性和压缩加速功能，将处理器从处理计算密集型操作中解脱出来，具体功能如下：

❑对称加密功能，包括密码操作和身份验证操作。
❑公共密钥功能，包括RSA、Diff ie-Hellman和椭圆曲线加密。
❑压缩和解压缩功能，包括DEFLATE和LZS。

另外，DPDK专门实现了一个Cyptodev的PMD驱动，与Ethdev的PMD驱动很类似，提供了一些加解密API，支持零拷贝技术来处理网络报文。

图13-8描述了一个简单的报文处理流程。网络报文通过网卡的PMD驱动接收上来，处理线程如果发现该报文需要加/解密，调用Cyptodev API把请求提交给QAT卡，QAT卡通过零拷贝技术直接对该报文处理。处理线程会周期性地轮询QAT卡的处理返回状态，如果处理完了，就调用注册过的回调函数，把处理好的报文交给处理线程，如果是要转发出去，就直接调用网卡的PMD发送函数。

169.服务质量的保证

我们之前提到，英特尔的x86平台会共享最后一级处理器Cache、内存以及IO控制器等资源。对这些共享资源的竞争，会导致一些对Cache或内存敏感的应用程序性能下降。在NFV应用中，一些VNF设备（如防火墙，NAT等）可能会运行在同一个x86平台上，由于它们对这些共享资源的使用率不同，会导致它们的时延、抖动等整体性能具有不可确定性。

为了避免这个不确定性，保证每个VNF设备的服务质量，Intel推出了Platform QoS功能，里面包含有Cache监控技术（Cache Monitoring Technology, CMT）、Cache分配技术（Cache Allocation Technology, CAT）以及内在带宽监控技术（Memory Bandwidth Monitoring，MBM）。这些技术实现在处理器内部，提供了一个管理这些共享资源的硬件框架。CMT监测基于线程级、进程级或虚拟机级的对最后一级Cache的使用率。MBM监测基于线程级、进程级或虚拟机级的对本地内存或远端内存（双路系统中）的带宽的使用率。CAT则可让操作系统或宿主机控制线程、进程或虚拟机对最后一级Cache的使用大小。

图13-8 基于Intel QAT加速卡的报文处理流程

比如一台x86平台上同时运行着两个VNF。一个VNF是对中断响应时延要求高，意味着它喜欢中断处理程序能一直驻留在处理器Cache里。另一个VNF对内存带宽要求高，意味着它有大量的内存操作，会不停地把处理器Cache的内容替换和更新。由于处理器Cache是共享机制，对内存带宽要求高的VNF则会对中断响应时延要求高的VNF有很大的干扰，使其对中断响应时延的需求得不到保证。这时Platform QoS功能可以提供帮助，通过CMT和MBM的实时监控，分析出这两个VNF对处理器Cache的需求不一样，再通过CAT把这两个VNF所使用的处理器Cache分开，使双方分别使用不同的处理器Cache，这样干扰就降低了。当然系统管理员或VNF本身也可以直接使用CAT技术进行精细的部署。

图13-9简单展示这种使用CMT、MBM和CAT技术的例子。操作系统或宿主机能够制定一些规则，通过从CMT、MBM反馈回来的信息，控制CAT来决定线程、进程和虚拟机对资源的使用。

图13-9 使用CMT、MBM与CAT技术的实例

如果想了解更多CMT、MBM和CAT技术，请参考Intel处理器手册。

170.实例解析和商业案例

目前，基于DPDK开发的VNF已经有很多，有开源的，也有一些商用了，比如Brocade公司的vRouter5600[Ref13-8]、Aspera公司的WAN Acceleration[Ref13-9]、Alcatel Lucent公司的vSR[Ref13-10]等。下面举几个例子来简要说明它们是怎么使用DPDK的，以及其性能评估数据。

171.Virtual BRAS

BRAS（Broadband Remote Access Server，宽带远程接入服务器）是面向宽带网络应用的接入网关，它位于骨干网的边缘层，可以完成用户带宽的IP/ATM网的数据接入（目前接入手段主要基于xDSL/Cable Modem/高速以太网技术（LAN）/无线宽带数据接入（WLAN）等），实现商业楼宇及小区住户的宽带上网、基于IPSec协议（IP Security Protocol）的IP VPN服务、构建企业内部信息网络、支持ISP向用户批发业务等应用。

Intel发布了一个vBRAS（virtual BRAS）的原型[Ref13-11]，通过对真实BRAS的模拟，构造了用户端（CPE）发出的报文通过QinQ隧道到达BRAS系统，BRAS根据QinQ标签计算出GRE号，再通过查找路由表知道下一跳的目的MAC和IP地址，以及MPLS标签，然后封装成GRE隧道去访问互联网。反之，互联网来的报文，先通过GRE隧道到达BRAS系统，BRAS先剥除MPLS标签以及GRE头，根据GRE号计算出QinQ标签，根据QinQ标签和目的IP地址查找MAC表，就知道目的MAC地址，然后封装成QinQ隧道到达用户端。简单来说，BRAS系统就是做了一个协议转换，具体什么协议其实不重要，重要的是知道BRAS系统的性能主要是由报文处理决定。图13-10是vBRAS的流程图。

图13-10 vBRAS流程图

根据这个流程图的复杂性，intel决定采用pipe-line模型，即一个报文会被几个子任务（线程）处理，主要由工作线程（Worker Thread, WT）、路由线程（Routing Thread, RT）以及负载均衡器线程（Load Balancer, LB）组成。详见[Ref13-12]。

关于负载均衡器的设计，虽然大多数网卡（比如82599 10Gb网卡）本身支持一些分流规则（f low director, RSS等），可以把报文分流到不同的网卡队列上，这样可以作为硬件负载均衡器。但其也有一个限制，即那些分流规则不是支持所有的协议。在这个BRAS模型中，82599 10Gb网卡的RSS不支持MPLS或QinQ协议。所以，需要实现一个软件负载均衡器。

一个高性能的软件负载均衡器有如下要求：

❑需要能够线速转发从一个网络接口接收的报文到另一个工作线程。
❑转发的报文应该尽可能地平均分配到工作线程上。比如有4个工作线程，不能一个工作线程承担70%的负载，而其他三个工作线程各承担10%的负载。
❑同一个流（相同的5元组）应该转发到同一个工作线程处理，以避免报文乱序问题。
❑有双向关联的流应该转发到同一个工作线程处理，因为对于这种流的处理，工作线程通常需要访问流状态的数据。在同一个工作线程处理，我们可以避免不同的线程访问这些流状态的数据，以提高cache的命中率。

DPDK ring机制是实现这种pipe-line方式的高性能负载均衡器的最优方案之一，可以高效地在不同线程传递报文。其DPDK ring的mbuf大小对其转发吞吐量也有影响。如果mbuf设置太小，经常用完，会影响性能；如果设置太大，会造成内存浪费，cache的粘合性也不高。

负载均衡器有如下两种模型可以选择。第一种（见图13-11）模型是有几个网络接口，就有几个负载均衡线程，负责报文的接收和发送，把工作线程和报文的收发流程隔开，工作线程专注在报文的业务处理上。第二种（见图13-12）模型是负载均衡线程只负责报文的接收，工作线程在业务处理完成后，还负责报文的发送。

图13-11 多负载均衡模型

图13-12 单负载均衡模型

这两种模型的选择跟负载均衡线程和工作线程的工作量有关系，需要看谁更容易达到性能瓶颈。如果负载均衡线程的工作量比工作线程的工作量大，用第一个模型更好，因为再增加工作线程数，其系统性能也不能提高，负载均衡线程是瓶颈。如果工作线程的工作量大，用第二个模型更好，因为工作线程会是瓶颈，增加工作线程数可以提高性能。

在这个模型中，还有几个表，需要做查表的动作。这些表包括有GRE号和QinQ标签的对应关系，用户端MAC地址和QinQ标签，IP地址的对应关系，以及路由表。在前两种表中，可以用DPDK的rte_hash算法；在路由表查找中，可以用DPDK的最长前缀匹配（LPM）算法。这些表的大小对性能也至关重要。在这个模型中，有多个工作线程，所以可以把这些表分成多个稍小的表，以避免冲突。

在设计时，需要做大量的实验，通过调整线程数的比例关系，用户数量，大页内存多少，线程和处理器核的对应关系，超线程的使用等，以达到对该模型的特性理解，知道最小资源能达到最大性能的平衡点。在虚拟化下，采用物理网卡直接透传机制，以获得和非虚拟化环境下接近的性能。

图13-13是大量实验做完后得出的vBRAS系统最优配置。它模拟4个网络接口，2个是连向用户端的，2个是连向互联网端的。它有4个负载均衡线程，每个对应一个网络接口。每一个负载均衡线程可以根据规则把报文送给8个工作线程中的一个。对于从用户端来的报文，工作线程还需把报文传给2个路由线程中的一个。

图13-13 vBRAS系统构建

更多的分析可以参考发布的白皮书：https://networkbuilders.intel.com/docs/Network_Builders_RA_vBRAS_Final.pdf，https://networkbuilders.intel.com/solutionslibrary

172.Brocade vRouter 5600

Brocade vRouter 5600是一款可在软件中提供高级路由功能而不降低硬件网络连接解决方案可靠性和性能的虚拟路由器。它可以通过高性能软件提供高级路由、状态防火墙和VPN功能。该平台采用创新的Brocade vPlane技术，可通过基于软件的网络设备提供与硬件解决方案不相上下的路由性能。

Brocade vPlane技术可利用Intel DPDK方案来交付非常好的性能，将路由器的控制平面与转发平面分离开来。如图13-14如示[Ref13-8]，这种方案提高了数据包转发性能。在各个x86内核上将转发功能分离开来可以避免资源争用，同时充分利用高速数据包管道架构。

图13-14 Brocade vRouter方案

173.小结

DPDK与网络功能虚拟化的融合提供了一条新的思路，把传统的网络功能节点移植到通用服务器平台变成VNF，以降低成本，方便设备扩容与升级。但是，如文中指出，我们在进行系统架构设计时需要考虑VNF设备本身的特性，并制定一套有效的评估方法，来帮助我们选择网卡虚拟化接口，轮询或中断方式，并利用DPDK方案来优化硬件加速功能。最后，希望大家能够从vBRAS原型设计中了解如何利用DPDK技术来设计VNF。