高性能文件传输框架,高性能计算框架

基于SPDK 加速框架的高性能PMEM Bdev

由于数据中心拥有大量高速网络和存储，主机的CPU资源面临的挑战也越来越大。为了解决此问题，常见的外部外围设备具有(r ) DMA ) directmemoryaccess ) [2]功能。例如，对于在主体上安装多个PCIe SSD并且读取和写入SSD的I/O操作，可以依赖于SSD设备的DMA功能。但是，主机计算机具有永久内存相关设备，本文中描述的永久内存主要是IntelOptanePersistent Memory。

当我们将PMEM存储器配置为ad (应用直接)模式时，持久存储器可以提供数据持久化的功能，但PMEM不像其他PCIe外部存储设备那样具有DMA功能，可以在向PMEM设备读写时减少CPU压力。因此，在SPDK[1]项目中使用PMEM设备时，CPU负载较高时会出现问题。本文介绍了具体问题和当前SPDK中的相应解决方案。

目前SPDK 中直接使用持久内存的问题

SDK的核心设计思想是利用较少的CPU资源，尽量发挥PCIe SSD等存储硬件的性能。总的来说，其核心竞争力在于单CPU core上的高性能I/O设计（高吞吐/高带宽/低延迟）SPDK提供了用户状态的高性能I/O堆栈，并提供了高效的APP应用程序框架。我们的APP应用程序开发希望尽可能使用spdk应用程序框架开发计划的重要意义在于异步以及非阻塞的模型。但是，在将持久性内存集成到SPDK框架中时，这个原则几乎被打破了。主要是由于以下两个原因。

PMEM设备没有DMA功能。即使将PMEM器件设为AD模式，在对PMEM空间进行读写时，仍然需要CPU的参加。

PMDK[3]库的当前限制。 PMDK提供了一系列软件库，如libpmem、libpmemobj和libpmemblk。目前，从SPDK编程的角度来看，存在两个大问题。

a. 当前，所有PMDK API都不支持异步操作。 SPDK主分支版本有基于libPMEMblk的PMEM bdev实现，仍然通过SPDK bdev接口实现异步API，但实际上对pmem的读写是同步的。关于PMEM的读写，完全依赖于CPU。

b. PMDK不提供卸载引擎支持。由于PMDK主要通过CPU对PMEM设备进行编程，因此目前PMDK暂时无法有效集成其他卸载设备。因此，如果应用高负载，则无法解决与CPU密切相关的瓶颈问题。

一般来说，在操作PMEM设备的整个I/O路径上，CPU成为重要的劳动力，没有喘息的机会。

想象一下在hyperconvergedinfrastructure (HCI )环境中，使用SPDK vhost target为主机上的每个虚拟机I/o提供服务的情况。无论SPDK vhost target继承的存储设备是PCIe SSD还是主机上有大量虚拟机，SPDK vhost在虚拟机读取和写入相应的虚拟磁盘时(使用virtio SCSI/blk协议) 由于SPDK vhost接收命令并将NVV传递给底层用户，因此可以为每个虚拟机提供良好的服务，例如，继续接收和分发其他虚拟机的I/O命令。最后，通过轮询检查每个虚拟机的I/O是否完成。此列的操作可以全部异步、相对公平，也可以相对控制每个虚拟机的延迟。

在SPDK vhost中引入当前的PMEM bdev时，这一用法被打破了。虚拟机虚拟磁盘映射到SPDK vhost中的PMEM bdev时。一旦SPDK vhost对该PMEM bdev进行I/O读写时，CPU必须参与整个过程。这种使用方法引起了两个问题：

I/O调度的公平性。其他虚拟机的latency具有重大影响。多租户性能隔离被完全打破，限制PMEM bdev的QOS使用，除非有更精细的粒度调度算法。这样调度算法就会变得非常复杂。

在操作33558www.Sina.com/PMEM设备时，大量的CPU时间用于完成PMEM相关的读写。意味着用更少的CPU做同样的事情。例如，如果SPDK vhost最初使用4个CPU内核驱动10个PCIe SSD，则可以很好地支持同时读取和写入16个虚拟机的I/O。在中，将这10个pcie固态硬盘更换为永久内存可能需要4个或更多CPU内核，例如6个和8个。那意味着能够在主机上分配给用户的CPU (仍然在HCI环境下)变少，提供HCI服务的(云)服务制造商不想看到它。更换速度更快的存储设备后，

服务I/O的CPU反而成为了一个瓶颈。导致可以售卖的CPU资源变少，从而增加了成本。导致这样的事情发生，这些云服务商客户甚至会进一步质疑SPDK框架对于使用PMEM设备的有效性。

目前的PMDK库没有提供异步的接口，长期来讲一定会加入异步接口以及基于硬件的卸载，满足类似SPDK这类库异步编程的需求。不过目前来讲，无法满足现有SPDK 集成使用PMEM设备的情况。为此，我们引入了SPDK acceleration framework (spdk accel_fw[4]) 来解决这个问题。

SDPK PMEM_accel bdev module介绍

SPDK accel_fw主要实现memory offloading engine的接口，目前封装了CPU/IOAT/DSA这三种设备进行（持久）内存的读写。利用SPDK accel_fw，我们在实现新的bdev—PMEM_accel bdev。SPDK pmem_accel bdev模块属于SPDK的bdev模块，目前还在开发过程中[5]。依然需要根据SPDK bdev相关头文件定义的接口实现需要的功能，比如对于块设备READ/WRITE/等操作的支持。图1给出了pmem_accel 和旧的pmem blk dev的对比。和旧的pmem bdev模块相比，主要利用了spdk accel_fw，尤其是封装在accel_fw中的DSA 硬件。

图 1 新的PMEM_acccel bdev 和旧的PMEM bdev

设计这个pmem_accel bdev的目标，主要是为了卸载CPU资源的消耗。我们的目标是利用SPDK accel_fw 中的memory offloading engine（IOAT 或者DSA），所以首先需要考量在哪些情况下我们可以用IOAT/DSA设备。我们知道Intel® Optane™ Persistent Memory 在格式化成AD模式的情况下，有两种模式。

FSDAX模式，在这种模式下面，在操作系统中看到的是一个块设备（诸如/dev/pmem0）。在这种模式下，用户可以直接对这个块设备进行操作，或者在上面建立文件系统，进行管理。然后如果SPDK application使用，可以在相应的文件系统中使用一个或者若干个文件，作为相应的pmem_accel bdev。

DAX模式。在这种模式下，系统中看到的是一个字符设备（诸如 /dev/dax0.0）这样的设备。用户可以通过字符设备的接口操纵pmem device。这个弊端是无法建立文件系统。SPDK application使用的时候，可以把PMEM的字符设备作为一个bdev。

图 2 CPU/IOAT/DSA 对于intel

傲腾内存访问的方式的可行性。

当我们用CPU在这两种模式下进行访问的时候，都是没有问题的。不过我们需要验证IOAT/DSA是不是可以在这两种模式下进行访问。笔者这边做了很多调研，暂时得出了图2中的结论。

首先在持久内存使用FSDAX的模式，然后在这个块设备上建立文件系统，其实有两种子情况。一种是使用“-o DAX”对已经建立好文件系统的PMEM块设备进行mount，这样可以bypass page cache，一种是不用“-o DAX”，也就是使用page cache。目前来看，FSDAX + “-o DAX”下，使用IOAT/DSA 是有问题的，这个问题需要内核的解决（比如Linux 内核）；使用FSDAX，IOAT/DSA设备可以直接访问文件系统中的每个文件。但是使用这种方法，并没有bypass page cache。也就是说实际上， IOAT/DSA设备访问的不是实际持久内存的空间，而是PAGE cache （CPU-> Page Cache-> 持久内存）。从而在掉电的时候，可能存在掉电的风险。

然后另外一种是DAX 模式，这种模式下IOAT/DSA都是可以直接访问进行读写。所以我们目前的PATCH[5]的开发中，我们选择了使用DAX模式来访问持久内存。虽然有一定的局限性，但是至少可以保证在使用IOAT/DSA设备的情况下，数据的持久化问题。

理想情况当然是把PMEM设备配置成FSDAX + “-o DAX”，但是这个短期来讲不容易解决IOAT/DSA访问PMEM的问题，可能需要内核中文件系统的支持。目前来讲，即使用CPU 访问FSDAX +“-o DAX” mount 情况下的文件，在linux内核也是一个experimental属性。所以我们选择把PMEM设格式化成字符设备，配合使用spdk accel_fw进行使用。

前面我们主要讨论是IOAT/DSA对于PMEM设备可访问的问题，但是对于数据持久化的问题。我们依然需要进行一些考量：由于我们使用了spdk accel_fw去操作PMEM。我们必须保证数据的一致性。也就是（1）在CPU cache，内存之间，持久内存中的一致性；（2）以及在机器掉电（power failure）时候，数据不丢失。当我们使用CPU对持久内存进行读写的场景，CPU一般可以使用clflush或者clwb把cache中的内存刷新到持久内存中。这些操作可以使用PMDK的库进行协助或者自己使用对应的汇编指令。那么如果我们使用了IOAT或者DSA library的时候，该怎么实现。笔者做了一些研究，发现IOAT似乎没有这样的功能，这就意味着掉电的时候，数据可能还在CPU cache或者内存中，那么显然在生产环境中使用IOAT 设备有一定的风险，尤其是进行写数据的时候，可能在机器掉电的时候丢失数据。然后检查了DSA 设备的spec，发现有这样的功能，那么就可以放心使用（还在开发过程中）。那么对于持久内存的操作，就可以直接绕过CPU cache/Memory，写到持久内存中，可以同时满足（1）&（2）的需求。

另外PMEM的访问，其数据写的原子性和PCIe SSD这样的块设备不一样。一般PCIe SSD块设备的原子写一般是512或者4096 bytes。对于PMEM的写原子性，可能还要小很多。为此如果PMEM_accel bdev在使用的时候，必须由上层来保证相应的原子性，包括需要实现必要的512或者4096之类的常见blocksize的原子性。

SPDK PMEM_accel bdev module的可能应用场景

SPDK PMEM_accel bdev可能有如下的使用场景，

Bdev独立使用的场景。也就是说PMEM_accel bdev不和其他bdev整合，直接整合在上层应用中。比如在SPDK NVMe-oF target程序中，对外提供块设备的服务。如果在SPDK NVMe-oF target中整合原有的pmem bdev，性能会比较差。但是使用了PMEM_accel bdev后，性能应该会有提高。

作为其他bdev的子模块。持久内存设备是比较昂贵的，直接作为SPDK的块设备存放数据，是比较浪费的，不一定满足所有应用的需求。一般来讲PMEM设备可以保存一些元数据，或者重要的log（比如WAL，write ahead log）。为此这个bdev可以和其他bdev一起使用，对于PMEM设备的读写，依然可以使用spdk accel_fw进行卸载。

总结和后续

这篇文章中主要介绍了SPDK 集成持久内存（主要是 Intel® Optane™ Persistent Memory）的时候，高负载情况下CPU 资源消耗过高，从而成为瓶颈的问题。为了解决这个问题，我们认为对于PMEM 设备的操作需要额外的memory offloading engine设备的协助。为此我们在SPDK框架中，利用SPDK accel_fw 设计和实现了一个新的bdev （pmem_accel） bdev。这个bdev可以使用SPDK accel_fw中的IOAT或者DSA引擎进行工作的负载（推荐使用DSA 引擎），从而降低CPU的使用率。

目前这个模块的代码虽然还在开发过程中，但是初始的patch已经公开，欢迎大家使用并且进行评估和反馈。可以在SPDK的mailing list，Slack或者SPDK github的相关页面联系我们，以进行相关的讨论。对于相应的性能数据，等待Intel的SPR 平台发布以及模块完善以后，不久的将来我们也会在SPDK 官网[1]进行分享。另外在阅读本文的同时，也可以参考笔者在今年China Infrastructure Day性能优化分论坛上的分享[6]。

Reference

[1]http://spdk.io

[2]https://en.wikipedia.org/wiki/Direct_memory_access

[3] https://pmem.io/pmdk/

[4] SPDK加速框架介绍

[5] https://review.spdk.io/gerrit/c/spdk/spdk/+/9304

[6]https://github.com/chinacid/cid_slides/blob/main/cid2021/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/4%20-%20%E5%88%A9%E7%94%A8SPDK%E5%8A%A0%E9%80%9F%E6%A1%86%E6%9E%B6%E6%9D%A5%E5%8A%A0%E9%80%9F%EF%BC%88%E6%8C%81%E4%B9%85%EF%BC%89%E5%86%85%E5%AD%98%E4%B9%8B%E9%97%B4%E7%9A%84%E6%95%B0%E6%8D%AE%E6%93%8D%E4%BD%9C_%E6%9D%A8%E5%AD%90%E5%A4%9C_10_28.pdf

转载须知

DPDK与SPDK开源社区

公众号文章转载声明