通信行业正朝着建立在标准服务器和云原生原则上的网络体系结构、操作和服务迈进。这需要高级的功能分区和硬件抽象来增加模块化和可移植性。即使我们在NFV上取得了共同的进展，我们还有更多的工作要做，以实现高性能的云原生数据平面。
由于硬件和软件的相互依赖，一些通信服务提供商(commsp)在部署和编排虚拟网络功能(VNFs)时遇到了挑战。应用程序数据平面依赖于硬件加速器和非云原生的特定平台配置。不断发展的输入/输出虚拟化标准(如VirtIO)具有性能限制。单根i/o虚拟化(SRIOV)解决了这些性能需求，但它的代价是降低了灵活性(例如缺乏动态迁移支持)。
在网络中，我们还没有达到这些层完全独立和相互抽象的分离水平，但我不认为这是我们的目标。与许多技术战略一样，有一系列的选择，没有一刀切的方法。
高级的ETSI网络功能虚拟化(NFV)框架帮助我们简化和划分VNF、MANO和NFV基础设施抽象。随着我们对NFV的扩展，NFV数据平面显然需要更多的关注。这篇博客探讨了一些可能帮助我们应对这一挑战的选择。
平衡硬件和软件数据平面的分解和可用性
我们需要推动硬件抽象，以消除软件数据平面的依赖关系，并确保今天的硬件加速器和下一代新的指令优化可用于VNFs。英特尔的方法是在英特尔®至强®处理器中集成具有竞争力的数据包处理和数据平面功能，以实现“应用程序和VNF加速”，以补充标准网卡和smartnic的基础设施加速功能。英特尔的观点是，这种平台分区，例如网卡和smartnic中的基础设施加速，以及cpu中的应用程序加速，将为越来越依赖数据包数据的下一代应用程序提供所需的可伸缩性。
云原生应用程序要求网络服务是抽象的，易于使用，没有任何平台依赖关系，同时提供更高的吞吐量和更低的延迟。硬件和软件之间的抽象仍在继续，数据平面进一步发展，以合并行业标准的网络硬件、公共api，并得到额外的自动化支持，以解决分层系统的解耦问题。
开源社区使用数据平面加速工具包(DPDK)支持抽象的发展
数据平面VNFs需要高性能网络接口、线路数据速率和最小延迟，所有这些都需要最小的成本。数据平面开发套件(DPDK)是这种进化的一部分。社区对该框架的实际NIC和硬件抽象的更新旨在支持云原生执行环境。
图1:DPDK演进到支持硬件抽象和云原生VNFsDPDK社区发布了18.05版，它支持许多新功能，包括:
- 动态内存扩展、中断驱动模式和共享内存数据包接口在应用程序实例之间提供了高性能的数据包发送和接收(例如容器到容器的消息传递)。
- 应用程序接口(ethdev, cryptodev, compressdev, security, eventdev, bbdev)使用软件等效功能增强已安装的平台硬件，以支持一致的基本功能级别。由此产生的多体系结构、多供应商环境支持可移植性和高性能，从而提供对底层可见平台的透明访问。
- 无线基带设备(bbdev)提供了一个通用的编程框架，该框架抽象了基于fpga和/或固定功能加速器的硬件加速器，以辅助3GPP物理层处理。
- 更新的Linux网络子系统(如AF_XDP)设置操作系统和网卡来虚拟化环缓冲区的传输和接收，而接收到的数据包是直接内存访问(DMA)到用户空间。与从用户空间进行原始PCI访问相比，这提供了一个在不同进程或容器之间利用OS标准隔离的选项。
- 基于策略的电源管理:使用细粒度的电源管理解决“始终在线”的网络用例。这支持通过低功耗模式或通过增加选择核心的频率来提高性能的潜在节省。
DPDK社区正在考虑对即将发布的版本进行以下改进:
- 更新的用户空间硬件驱动程序构建在操作系统通用设备支持(即中介设备框架)之上，并适应遗留的虚拟化接口(例如VirtIO)。通过在DPDK接口下安装用户空间驱动程序，该框架节省了VM出口/入口，支持动态迁移，并消除了改进或开发额外虚拟接口(例如VirtIO_crypto)的需要。对于网卡、加速器、GPU和FPGA加速设备也是如此。
- 建议添加的Resource Coordinator将可用的硬件实例动态连接到目标应用程序实例，并与外部编制或本地配置协调
加入协作，加速云原生部署
英特尔与我们的合作伙伴合作，以标准的方式解决与VNF可移植性和入职过程相关的挑战。DPDK社区定义并实现了硬件抽象框架。这将提供所需的可伸缩性，同时使VNFs可见并可用新的性能增强功能，以实现高性能和每瓦性能效率;NFV和网络转换的基本原则。
让我们合作，加速我们的云原生之旅。
在推特上关注我@rgadiyar继续谈话，拜访https://www.intel.com/network获取更多信息。
在简报页中获得可用于克服NFV挑战(如硬件和软件依赖关系)的解决方案的概述”敏捷地提供NFV性能，这样您和您的团队就可以实现组织的NFV愿景。
