Neutron社区每周记(12.12-12.16)| 你相信一条指令能传输一个以太网帧吗?

背景介绍

NFV,即网络功能虚拟化,旨在利用标准的标准的硬件,在商业服务器COTS(ommercial off-the-shelf)上,尤其是x86平台,对网络功能(network function)如路由器、防火墙、CPE等进行虚拟化,减少上市时间(time-to-market),运营和维护成本等。

由ETSI推出的一系列规范旨在建立一个NFV体系结构(详细参考见:http://www.etsi.org/technologies-clusters/technologies/nfv)。

通俗地,我们可以认为NFV是一种软件定义电信基础设施的手段,即电信云。到这里,相信大家已经很可能想到:OpenStack作为开源IaaS最热门的解决方案,与NFV结合应该是非常好的选择。

作为开源领域的专家,Red Hat对NFV做出了尝试(参见:Red_Hat_OpenStack_Platform-10-Network_Functions_Virtualization_Product_Guide-en-US.pdf),Red Hat认为:NFV有意义的前提是虚拟化的网络功能(VNF)在性能上至少不比物理设备实现低。这显然是对数据面性能的一个挑战。

那么第一个问题显然是商业X86服务器能线速地承载一个或多个10GE、25GE、40GE甚至100GE速率地以太网网络接口卡(NIC)?Intel DPDK的出现使得这个成为可能,关于DPDK这里不再介绍,但是根据UnitedStack有云网络团队的经验,一个开启超线程的核对intel 82599 10G 以太网卡数据包接收核发送/接收能力在14Mpps(帧长64字节),因此对于面向DPDK的应用,数据面业务很容以在端口密度核cpu核上可扩展。

假设数据帧可以以线速的方式进入/离开宿主机,那么数据帧是否有能力线速的在虚拟机(在NFV体系结构中,网络业务运行在虚拟机[广义地,包括容器]中)快速转发呢?由于数据进入宿主机Host内存中,数据的下一步流向基于软件实现,这个过程是一个CPU费时的,DPDK现有的解决方案可以表明,宿主机与虚拟机(容器)之间的虚拟链路相对于硬件来说确实是一个瓶颈,下图(来自DPDK2016summit)列出了不同的虚拟链路的性能测试结果:

1

可以看出基于virtio-pci这种IPC规范的数据传输确实是一种高性能的解决方案,且比传统的Linux kernel、pcap甚至af_packet虚拟链路要高出不少。但这是宿主机到虚拟机(容器)的虚拟链路的极限性能了吗?

UnitedStack有云网络团队的工程师相信可以通过可以摒弃这种基于virtio-pci的数据传输方式,进而使用一种平台友好(x86 向量指令处理,更好的cache布局)的IPC机制来构建性能更好的虚拟链路。

高性能虚拟链路

作为实践,我们使用了一种向量化的ring buffer来作为宿主机和LXC容器之间通信的机制,并封装在DPDK PMD驱动中,下文称之为eth_vecring,从而原生地支持任何基于dpdk的应用。下面的图给出了eth_vecring总体结构视图:

2

在容器启动前,应该配置mount hugetlbfs,并且将之映射到lxc容器中,接下来eth_vecring(master,通常处于host中的pmd称为master,容器中的pmd称为slave,用于区分对该pmd来说,共享内存的方向)pmd会自动探测大页并分配一定的内存和记录虚拟链路的元数据。接下来,虚拟链路两端的PMD可以以类似全双工的工作方式往这个buffer中以一定的数据格式读写数据帧。下面我们先看这个虚拟链路的测试性能。

测试拓扑如下:

3

即宿主机和容器中均使用pktgen-DPDK来对虚拟链路进行发/收包测试,使用4个开启超线程的core,且四个core均在同一个socket上。

DPDK虚拟链路的eal参数如下所示:

111

其中,domain为一个容器标识,Link为虚拟链路名称,mac为虚拟链路pmd端的mac,master在host中的pmd指定,容器端可以不用指定,socket优先分配大页的numa 节点。

对于64字节最小数据帧来说:

4

其单核收包或者发包的吞吐率在18Mpps以上。

对于1514字节数据包,单核收发包如下:

5

即2Mpps(25Gbps),如果两端同时发送和接收:

6

同时发送和接收后1514字节数据包,单核处理能力在1.3Mpps(16Gbps),原因是eth_vecring是基于内存在为IPC通道的,很可能受限于同一个socket的前端总线传输能力。

那么eth_vecring在跨numa的接收能力会有什么影响呢,经测试,总体吞吐率在64字节大小帧长下由最初的18Mpps下降到13Mpps,这是一个非常大的性能损耗,因此,numa在内存访问的时候,占据至关重要的因素。

向量化的Ring Buffer

ring buffer本质上是一个静态数组(连续内存空间)数据结构存储的队列,在eth_vecring,所有的队列元素大小一个cache line size ,在X86_64 上,64字节。且队列起始地址也按照64字节对齐(从而保证所有的队列元素都是对齐的,这一点尤为重要,因为很多SIMD指令对内存的访问要求地址按照一定的粒度对齐)。

eth_vecring传输的数据帧均会拷贝到队列中,这样所带来的好处是减少虚拟链路两端的依赖性。因此内存拷贝是性能所在的关键,在eth_vecring的是现在,我们以sse/sse2/sse4.1/sse4.2(128bit)指令和avx/avx2(256bit)来进行内存的操作。一个很明显的事实是:无论是拷贝进入队列的数据或者是从队列中拷贝出来的数据,在很长一段时间内很可能不被使用,因此这个过程是non-temporal。

所以,在数据拷贝过程中,我们没有必要将队列相关的数据让cpu load到cache中,即我们要bypass cache,这么做的好处就是PMD的行为(即大量的内存IO行为)不会干预并且污染真正数据面业务已经load到cache中的数据。

很可能有人会问,这种拷贝真的高效吗,因为数据离cpu越远,所需要的内存访问时钟周期越多,比如L1d cache的访问时钟周期为1-2 cycles,L2 cache 访问为12 cycles,memory 访问为~140 cycles,那么绕过cache 所带来的内存访问开销会大很多,但是由于writing-combine以及stream-loading-buffer的存在,这种non-temporal的行为在真正和memory交易的时候是以cache line size为单位的,并且如果虚拟链路的IO如果污染cache,那么给数据面业务带来的性能损失将会是巨大的,另一方面,cache bypassing很可能会在总线空闲的时候将内存写回write back到memory,因此并不见得cache bypassing会非常低效。

对队列的操作是以cache line size为单位的,接下来简述cache line copy的实现avx-256实现:

7

对于对齐的地址,我们可以使用单条stream load SIMD指令将地址中的32字节的数据load进ymm寄存器(编译器自动编排寄存器序号)中,紧接着stream store到要拷贝的地址中。对于没有对齐的地址拷贝,只能将数据load到cache中来。eth_vecring会自动判断地址的对齐与否。

数据包传输是以16字节的头部为标识的,eth_vecring在传输的时候采取了类似virtio-pci中的emergable特性将最多4(一个cache line最多容纳4个16字节头部)个数据包头部合并在一起传输,报文传输头部以及数据块定义在下面的代码框中:

8

除了对内存的布局和访问做出优化外,队列传输的代码均用SIMD指令进行优化完成,别且使用inline以及branch prediction来提高L1i指令cache 的效率,这里将不再详述。

总结

回到题目的问题,一条指令能传输一个以太网帧?当然不可能,但是这并不妨碍我们从另外一个角度看待platform friendly IPC对虚拟链路的提高有着巨大的潜力。

随着AVX-512指令集对内存访问的支持,引入512-bit的zmm寄存器,那么对于一个512bit的数据,一个vmovntdqa指令即可完成从寄存器到memory的数据传输,恰好cache line size是64字节,恰好以太网最小帧长是64字节。(作者:陈杰,UnitedStack有云)