摘要： 摘要 这篇文章介绍了阿里云开发智能网卡的动机、功能框架和软转发程序以及在软转发过程中发现的问题和优化方法。 主讲人陈静 阿里云高级技术专家 主题Zero-copy Optimization for DPDK vhost-user Receiving 分论坛Network & Orchestration 项目背景 在VPC产品部署中虚拟交换Virtual Switch承担着overlay层和underlay层进行网络协议的加解密encap/decap功能在多租户虚拟机或者容器的主机上也需要进行二三层的路由转发、Qos、限流、安全组等。
摘要： 这篇文章介绍了阿里云开发智能网卡的动机、功能框架和软转发程序，以及在软转发过程中发现的问题和优化方法。
主讲人：陈静 阿里云高级技术专家
主题：Zero-copy Optimization for DPDK vhost-user Receiving
分论坛：Network & Orchestration
项目背景
在VPC产品部署中，虚拟交换（Virtual Switch）承担着overlay层和underlay层进行网络协议的加解密（encap/decap）功能；在多租户（虚拟机或者容器）的主机上，也需要进行二三层的路由转发、Qos、限流、安全组等。虚拟交换现在业界有比较被广泛接受的OVS开源项目，在阿里云上，我们也开发了针对自身业务相契合的AVS项目。AVS有和OVS类似的功能，也同样是纯软件的实现方式，在我们使用过程中，发现了一些问题，从而催生了智能网卡项目。
首先，AVS占用主机资源。AVS作为软件，需要占用主机侧的计算资源、内存资源，当吞吐量大时，还会占用大量的LLC cache资源，而本来这些资源更好的利用方式是交给客户，增加资源的利用率。
其次，性能瓶颈。在云上业务部署过程中，应用对网络带宽的要求在不断提高，纯软件的方式已经慢慢跟不上这种需求，因此有必要用对AVS进行加速。
基于这两个原因，我们进行了智能网卡项目。
Virtio or SRIOV？
众所周知采用PCI-E SRIOV技术的VF设备，通过PASS-THROUGH的方式呈现在VM，具有高性能、功能丰富的特点。但是缺点也同样明显，比如热迁移（hot-plug）不方便；不同厂家提供的VF接口不一致；需要额外的驱动等等。virtio作为业界比较通用的一种虚拟设备接口方式可以解决之上的各种问题，但是问题在于目前暂时没有完全支持virtio接口设备的硬件厂商，其是使用软件模拟实现的一种方式，因此性能不是很好。那么，有没有一种又有高性能，同时支持virtio的解决方案呢？
我们结合virtio和SRIOV的优势，设计了一套基于软转发的方案。
智能网卡方案
下图是我们的智能网卡的框架设计，在卡上有一个标准的网卡ASIC和一个片上系统，片上系统自带内存和CPU。AVS运行在片上系统，把快速路径（fast-path）卸载到ASIC中，而自身只负责慢速路径（slow-path）的处理。通过快慢速路径分离的方式，不但减轻了软件AVS的处理负载，也大大提高了吞吐率。
在智能网卡实现过程中，由于我们的标卡没法做到virtio-net的硬化，所以对host的输出只是一个提供商定义（vendor-specific）的VF接口。同时，在客户侧（VM
），我们期望用户不用做任何的修改，沿用virtio-net接口。在这种需求下，我们开发了一个简单的、基于DPDK的软转发程序。由于AVS在网卡已经完成了所有的策略、逻辑、路由、多队列的所有功能，VF和virtio-net前端有一一对应的关系，而软转发程序只需要完成VF和virtio-net的接口转换和报文传递即可。同时，我们也不能为该软转发程序分配很多资源，否则就和我们最初做智能网卡的初衷背道而驰。因此，软转发的性能成为了我们非常重要考量的指标。在描述我们的优化方法之前，我们先了解一下常规路径。
报文接收路径
在讲到报文接收路径之前，有必要介绍一下DPDK中接收队列的初始化方式。首先，软件需要在内存中分配一段缓冲区作为队列，队列中的数据结构称为描述符（descriptor），这是软件和硬件交互的接口；如果是virtio-net这中para-virtualized模拟设备，前端驱动和后端驱动交互的接口。除此之外，软件还需要一个内存池（memory pool），里面都是固定大小的数据缓冲区，用来承载网卡发送过来的网络报文。
初始化接收队列之后，网卡就可以开始正常工作了。当从网络中接收到报文之后，按照下图所示进行处理，最终送达到对应的虚拟机。
首先，报文缓存在智能网卡上，然后进行快速路径或者慢速路径的处理，最终判断是发送到哪一个VF，哪一个接收队列。
接着，网卡会从对应的VF接收队列读取描述符，获得存储报文的地址，然后进行DMA操作，最后，回写描述符到接收队列，描述符中包含了报文长度、类型、错误标志位等信息。
软转发程序通过VF接收队列的描述符发现收到了一个报文，接着会读取VM中的virtio-net的接收队列描述符，获得需要拷贝的虚机中的DMA数据地址，通过memcpy的方式拷贝报文；接着，更新virtio-net的描述符信息，通知前端驱动，整个逻辑完成。
优化后的零拷贝接收
从之上的过程可以发现在报文送到虚拟机的整个路径中，报文被拷贝了两次：一次是硬件DMA到主机内存，另外一次是软转发程序拷贝报文到虚拟机的Guest memory。特别是后一次是非常消耗CPU时间的操作。从我们后来的性能profiling也可以看到内存拷贝占用了很大的比例。那么，能不能减少一次拷贝呢？
综合以上的需求，我们设计了接收端的零拷贝方案。主要是设计了一个队列同步模块，如下所示。
它主要的作用有以下几个：
1.   在前端virtio-net和SRIOV VF队列的描述建立1：1的映射关系。
2.   监控前端virtio-net 接受队列描述符的改变，同步到VF的接收队列中。这样，在VF的接受队列中就不需要内存池来缓存从网卡上收到的报文，而直接用虚拟机传递的缓存。
3.   进行虚机物理地址（Guest Physical Address, GPA）到主机物理地址（Host Physical Address, HPA）的转换。在virtio-net的VF中，驱动填充的是GPA地址，在没有利用IOMMU的情况下，需要把GPA转换成HPA，这样智能网卡才能进行DMA传送。
在有了队列同步模块之后，报文的接收过程如下图所示。
主要改进在于智能网卡直接DMA到虚拟机指定的内存中去，并且硬件还不感知这个变化。软转发程序只是简单的将VF接受队列的描述符信息进行转换，填充到前端virtio-net的接受队列中去。
零拷贝的优势
经过测试和分析，我们觉得零拷贝有如下的优势：
lã�� 性能
接收端减少了内存拷贝
Footprint减少，避免cache-coherency
总体性能提高了40%
2、时延
减少拷贝带来的时间开销
本文为云栖社区原创内容，未经允许不得转载
网友评论