NBJL 2020论文导读20： LeapIO: Efficient and Portable Virtual NVMe Storage on ARM SoCs
张佳辰
2020年4月24日
论文下载地址：https://ucare.cs.uchicago.edu/pdf/asplos20-LeapIO.pdf
presentation地址：https://www.youtube.com/watch?v=Gyn9eABQwTQ
论文信息：
论文发表于ASPLOS 2020，作者是来自University of Chicago的Huaicheng Li等人。
论文简介
近年来，很多云数据中心开始在服务器中部署ARM协处理器，这是因为ARM处理器相对低廉的成本以及可以媲美x86的性能。但当前的ARM协处理器主要用于服务SmartSSD、SmartNIC，或者卸载一些x86主机的计算任务。LeapIO探索如何将复杂的云（虚拟化）存储栈卸载到ARM核上。
由于云对存储资源的管理和隔离有较高需求，复杂虚拟化存储栈不仅拖慢了虚拟磁盘的性能，还带来了宿主机x86核的开销。文章中形象地将虚拟化存储栈所消耗的宿主机计算资源称为“存储税”，“存储税”占了宿主机10-20%的计算核心，因此使用成本过高。ARM核相对x86核价格更低，功耗也更低，因此整体使用成本可以降低很多倍。因此，文章中的主要工作时解决将虚拟化存储栈卸载到ARM SoC的各种具体问题。
LeapIO将virtual NVMe暴露给客户机，使用NVMe作为抽象层协议，x86/ARM/QPI/PCIe之间都使用NVMe所定义的queue-pair进行通信。LeapIO以其软件核心“runtime”为存储服务提供统一的地址空间和透明的地址转换，隐藏了NVMe映射的复杂细节。
文章还提出“SoCvm方案”，支持将LeapIO runtime运行于x86宿主机的虚拟机中，来在服务器不满足ARM SoC硬件要求的情况下部署LeapIO。SoCvm方案体现了一种可替代/移植的特性，这有利于系统的实际部署和维护。
论文的测试部分也说明，LeapIO方案相对设备passthrough的方案，性能损失很小，并且其提供的存储服务能满足为搜索引擎等应用对存储资源隔离和管理的需求。
论文内容
2.1. 设计目标
首先，论文的设计目标包括如下几点：
可替换性和可移植性：LeapIO runtime可以运行于x86宿主机或者ARM SoC上，这保证了对于不同配置的机器都可以使用统一的LeapIO runtime提供存储服务。比如有些老机器没有SoC、RDMA等硬件支持，也可以用主机的核运行LeapIO runtime。
虚拟化和可组合性：虚拟NVMe和本地或远程的物理存储设备不必是一一对应的，可以组成类似RAID的“多对一”形式的，并且不同的功能之间应该是可以叠加使用的。
高效性：（1）polling虚拟NVMe的提交和完成队列；（2）通过统一的地址空间，减少不同软硬件组件（x86中的VM、SoC中运行的服务、网卡设备、SSD设备等）间的数据拷贝。
服务可拓展性：不像实现于kernel层的块级服务或实现于FPGA的服务，LeapIO实现于用户态，方便云提供商的管理、配置，并支持多个复杂存储服务的组合配置。
2.2. 硬件要求
为了实现设计要求，LeapIO需要硬件支持如下特性：
SoC可以访问Host DRAM。（上图中的①）
SoC可以使用IOMMU来完成guest虚拟地址和host物理地址之间的转换。（上图中的 ②）
SoC的DRAM需要通过PCIe BAR被映射到host的物理地址空间，这样RDMA NIC、SSD、host和SoC自身就可以通过host物理地址来访问SoC DRAM了。（上图中③）
NIC共享：网卡设备需要可以在x86 host和ARM SoC之间共享。（上图中④）文章中的实现方式是将NIC功能集成到ARM SoC之上，避免了对独立NIC设备的更多硬件要求。（上图中NIC**）
2.3. 软件架构
在软件方面，LeapIO不仅要负责各种控制平面映射的建立，还要负责实现高性能的数据路径：
a. VM中的存储设备抽象是NVMe设备(/dev/nvmeXnY)
b. host OS只负责queue-pair在VM和SoC中leapIO runtime之间的映射，数据路径会bypass host OS；
c-d. 当以本地存储作后端时，LeapIO还将在host DRAM中建立SSD和SoC之间的queue-pair映射。
c-e. client端：（当使用远程存储服务时，分为client和server端）client程序在SoC的userspace开发，bypass了OS，并且用polling来提升性能。
e. NIC：client和server端的SoC通过内建的NIC进行IO请求的传输。
f. server端：和client端类似，runtime也是polling queue-pair，也是实现于用户态，并且也可以进一步向远程转发或者请求其本地SSD。
2.3. 控制面的建立
如上图，VM和LeapIO runtime间建立queue-pair映射：queue-pair实际保存在host的DRAM中。
LeapIO和SSD都映射一段host DRAM的另一个queue-pair：由上图可以看出，SoC映射两组queue-pair。第二组是SSD和LeapIO之间共享的queue-pair，但实际也是host DRAM中被创建。LeapIO负责将红色queue-pair的IO请求根据所配置的各种存储功能进行转换，并发送到另一组橙色queue-pair中。
2.4. 数据路径
（一些缩写的说明：gA: guest virt addr hA: host phy addr vA: host virt addr sA: SoC phy addr lA: SoC virt addr）
上图中，数据路径分成了a到f的多个流程。其中，runtime指运行于ARM SoC的LeapIO核心程序，sRAM指SoC物理DRAM内存，hRAM指宿主机DRAM内存。图中假设了一个将一台远程机器上的SSD作为存储后端的情况，来说明LeapIO的数据路径。
图中实心红色方块和箭头展示了数据路径中数据拷贝的流程(Host DRAM --> SoC DRAM --> remote SoC DRAM --> SSD)。其中，
Host DRAM --> SoC DRAM由于是跨越了PCIe总线，所以会导致一次
可避免的拷贝，不过实际的数据搬运是由DMA负责而不需要host x86核参与；SoC DRAM --> remote SoC DRAM的拷贝是本地SoC和远程SoC之间的RDMA传输，不需要host的参与；remote SoC DRAM和SSD之间的拷贝由SSD DMA负责，同样不需要host的参与。
由于拷贝被尽量减少，数据传输过程伴随着各种地址转换的需求：
Host DRAM --> SoC DRAM过程中，由于SoC需要通过gA要得到hA，因此需要IOMMU的支持。由于remote SoC DRAM --> SSD的DMA传输需要hA，因此需要lA->sA->hA。sA要被提前映射为host地址空间的一部分，来实现sA->hA的转换。
（3）远程服务端地址转换：由于remote SoC DRAM的数据最终也要被DMA搬运到SSD中，而SSD DMA只能通过hA来搬运。sA->hA的转换需要硬件特性3：SSD和ARM SoC两种PCIe设备之间的p2p传输技术。
2.5. SoCvm
SoCvm（上图“SoC-in-VM”）基于一个普通的x86虚拟机，它的提出让LeapIO不仅可以运行于ARM SoC（上图SoC ARM）中，也可以运行于x86宿主机中，减弱了对SoC硬件的依赖，让LeapIO runtime可以运行在一个VM中。
由于SoCvm和SoC一样也需要对host物理内存的访问，所以host创建SoCvm时会将整个host DRAM物理地址空间映射到SoCvm地址空间的末尾（如上图）。
2.6. 性能测试
文章中的测试部分为了消除SoC硬件影响，首先将LeapIO运行在了SoCvm中，比较单机SSD存储中LeapIO方案和passthrough方案、全虚拟化、半虚拟化、SPDK等方案的性能，然后对比了LeapIO服务和NVMeoF的对远程SSD的访问性能。这些实验说明了LeapIO软件栈相对其他虚拟化存储栈仅有很小的性能损失。
之后，文章中将LeapIO运行在了实际ARM SoC中，对比运行于SoCvm中LeapIO的性能，ARM SoC版本有30%的性能损失。但这个性能预计会随着SoC硬件的升级而提升。
文章最后还以搜索引擎应用为例，用实验说明LeapIO所提供的IO优先级、IO隔离、快照等存储服务可以保证让服务器同时服务低延迟搜索请求和后台索引更新。
具体的测试数据可以在论文中找到。
总结和体会
ARM核的价格和功耗远低于x86核，因此近年基于ARM的SmartNIC、SmartSSD甚至ARM服务器成为了工业界和学术界的关注热点。相比于SmartNIC、SmartSSD和定制化的ARM计算加速卡，LeapIO更深入地利用ARM编程的通用性，将可以软件定义的云虚拟化存储栈全部卸载到ARM SoC上，节省了云存储中的虚拟化成本。功能和性能上，低成本的LeapIO可以和宿主机内核存储栈或宿主机用户态SPDK存储栈媲美。
文章中的亮点之一在于提出了一种真正切实可行的存储栈卸载方案，并且对于各个实现细节都进行了说明。
另外，实现真实SoC卸载方案的同时实现SoCvm也是一种值得借鉴的项目开发方案，SoCvm同时方便了系统的开发和部署，逻辑上也体现了x86核与ARM核对于虚拟机一种对称性。