专栏首页虚拟化笔记virtio+ovs转发原理和性能分析

virtio+ovs转发原理和性能分析

virtio和ovs介绍

传统数据中心中硬件服务器上运行linux,linux用硬件网卡收发包,硬件网卡有broadcom的有mellanox的有intel的等各式各样的,硬件网卡连接到硬件交换机上,硬件交换机有H3C的有cisco的,交换机进行包转发实现服务器之间互通。在云计算环境下,对计算资源进行了切分,服务器上运行的是一个个虚拟机,虚拟机也要有网卡实现互连互通,但虚拟机的网卡不是物理的,是虚拟的网卡,虚拟的网卡连接到虚拟的交换机上,虚拟的交换机对同一个服务器上的虚拟机之间流量进行转发,如果虚拟交换机再连接到服务器的硬件网卡,那么虚拟机就可以和服务器外面通信了。

硬件网卡收包时,CPU先分配内存,然后告诉硬件网卡内存的地址,报文从硬件交换机出来后进入硬件网卡的队列,硬件网卡通过DMA功能把包从物理网卡搬运到内存中。然后中断CPU说报文收上来了,CPU处理中断,软中断执行内核协议栈处理,最后通知应用程序收包。

虚拟网卡是CPU模拟出来的,它的队列也是模拟出来的,就是服务器上的一块内存。要模拟DMA功能就得进行一次内存拷贝,这次内存拷贝比较特殊,从服务器上拷贝到虚拟机里,虚拟机运行在服务器上,用的也是服务器上的物理内存,相当于服务器上物理内存之间的拷贝,只是地址转换比较复杂。

应用程序调用发包时,内核协议栈模块分配一块内存,把用户态要发的内容拷贝到内核。然后经过复杂的协议处理,最后地址告诉硬件网卡说我要发包你发完了告诉我一声,硬件网卡的DMA就把要发的数据从内存中搬运到物理网卡的队列中,然后告诉CPU说发完了,你可以回收内存了。

虚拟网卡发包和物理网卡发包类似,包从虚拟机中搬运到物理服务器内存中,然后经过软件交换机,最后从物理网卡出去。虚拟网卡有e1000,virtio等,为什么云计算环境最终选择了virtio?因为virtio首先提供了一种虚拟机和物理服务器数据交换的通用机制,虚拟网卡虚拟硬盘虚拟显卡虚拟串口等都可以用。其次virtio还分frontend和backend,frontend运行在虚拟机中,backend运行在物理服务器上,frontend和backend配合实现具体的网络功能,frontend和backend之间用virtio通用机制交换数据,设计真是十分巧妙。 virtio得到了大多的hypervisor支持,成了虚拟化事实上的标准。

硬件交换机是进行二层转发的,学习MAC进行转发,用STP协议防止环路出现,为了减小arp这样的广播风暴又增加了vlan隔离。软件交换机有linux bridge,vpp,ovs等,为什么云计算环境中大多用了ovs?因为云计算是最自然的SDN应用场景,不再需要复杂的控制面协议,如STP。另外云计算要求灵活,vpp pipeline和linux bridge设计时考虑更多的是二三层转发原理和转发性能,要加入新功能异常艰难,而ovs采用了openflow pipeline,多table和多group灵活跳转。pipeline设计考虑更多的是功能实现,性能方面由datapath支撑,并且datapath upstream到kernel中了,顺手就能用了,所以选择ovs。

vhost-net

这张图来自于redhat的博客,博客地址在参考文献中,非常完美的一张图,就没必要重复造轮子了。操作硬件网卡就是读写硬件网卡的寄存器,现在的外设都是PCIE外设,有配置空间和BAR空间。配置空间是PCIE标准定义,BAR空间硬件自己定义,读写寄存器就会触发硬件相应的操作,比如发送包,会构造一个ring,每个ring指向skb,然后把ring的头写到一个寄存器,再写一下触发发包的寄存器,硬件就读取ring,把ring指向的skb都从内存搬运到网卡上去。

虚拟机也有模拟的主板芯片和PCIE总线,virtio-net是PCIE总线上的一个外设。在这张图中frontend就是guest kernel中的virtio-net driver,而backend是qemu模拟的virtio-net device。virtio-net driver读写寄存器,qemu就要把原来硬件干的活模拟一遍。因为虚拟网卡寄存器是不存在的,kvm就把一块内存做特殊标志当作寄存器,virtio-net driver一写这块内存,cpu就从guest中exit出来,停止执行guest,开始执行qemu代码模拟guest触发的动作。qemu把外设模拟分为两种:控制面模拟和数据面模拟。控制面模拟有feature协商,vring地址交换等;数据面模拟有数据搬运和消息传递,其中消息传递就是guest通知vhost-net数据准备好了,我要发送,vhost-net发送完后告诉guest我帮你发送完了。在这张图中qemu把数据面模拟的工作交给了内核的vhost-net模拟来完成。

上面说虚拟网卡模拟DMA是内存拷贝,既然是内存拷贝那干脆共享内存就不用拷贝了。vhost-net就是这么干的,不管是内存拷贝还是内存共享都要进行内存地址换算。guest中的virtio-net driver设置的都是guest physical address,而vhost-net只知道host virtual address,但别忘记guest的内存是qemu分配的,qemu知道换算关系,qemu就通过vhost protoco告诉vhost-net模块换算关系。剩下就是消息传递了,kvm给qemu提供了api,qemu创建出两个eventfd传递给kvm,qemu通知guest,写一个fd,kvm读这个fd,kvm再把中断注入guest中,这个方向的通知叫做call。guest通知qemu,guest写寄存器,kvm拦截,kvm写另一个fd,qemu读这个fd,这个方向的通知叫做kick,qemu干脆一狠心,把这两个fd仍给了vhost-net,说以后这两个fd的读写就交给你了。

  • guest发包流程

guest在内核中分配skb,把地址写到vring中,kick kvm,kvm再通知vhost。vhost是内核线程,vhost地址换算拿到了skb,复制skb,通知guest发送完成,guest回收sbk,vhost继续给skb找netdev,加入到一个cpu的backlog,触发softirq,这个cpu的softirq发现netdev绑定在ovs桥上,查ovs流表找到出接口,调用物理网卡的驱动发送出去,物理网卡发送完成,把skb释放。

  • guest收包流程

guest中的virtio-net driver分配skb,设置到vring上,物理网卡驱动分配sbk设置给网卡,网卡DMA,中断触发,在softirq发现物理网卡绑在桥上,查ovs流表找到虚拟机的tap口,把skb放入tap的队列中,叫醒vhost worker,vhost worker醒来一看skb到了tap队列中,把skb拷贝到guest分配的skb上,通知kvm包来了,kvm再中断guest。

vhost-user

这张图也来自于redhat的博客,我做了一点修改,原图guest中运行的是virtio-net-pmd而且还有vIOMMU。考虑到guest中的难度,我觉得公有云上是不现实的,让用户在guest中搞hugepage和dpdk pmd难度很大,而且目前没有配套的成熟用户态协议栈,修改一下假设guest是最普通的guest,相比vhost-net一点也不变。这种模式ovs不再用内核的datapath,物理网卡绑定了DPDK,物理网卡直接把包DMA到用户态ovs,ovs进程和qemu进程共享内存把包传递到qemu进程中,qemu进程地址换算一下包就到了guest中。virtio-net控制面模拟还在qemu中,原来给vhost-net下配置的vhost protoco变成了vhost-user protoco把配置交给了ovs-dpdk进程,qemu和ovs-dpdk之间建立了unix domain socket。这个socket的神奇之处在于不仅能传递virtio配置信息,还能传递qemu和kvm之间通信的kick/call fd。qemu把virtio-net数据面模拟交给了ovs-dpdk进程,消息通道还是靠kvm。guest中一直poll不现实,但ovs-dpdk从guest中拿包时可以一直poll。

virtio full offload

这张图也来自于redhat博客,根据我自己的理解修改一把,保持guest不变,用户在物理机上怎么部署业务,在虚拟机中也怎么部署业务,不能让用户感觉到不习惯或者不舒服。整体原理就是把virtio backend都由硬件实现了,然后用passthrough功能,和普通的物理网卡passthrough一模一样,只是这块卡实现了virtio标准。 passthrough和dpdk都用了vfio-pci,原理一样,把物理网卡的pcie配置空间映射到qemu进程或者ovs-dpdk进程空间中,ovs-dpdk就直接读写,但qemu还得再地址转换一下给了guest,guest中的virtio-net driver就可以直接读写了,所以virtio kick就好搞了,但call还是经过vfio-pci,vfio-pci通知kvm,kvm再中断注入guest中。数据搬运就是硬件直接DMA到qemu进程或者ovs-dpdk进程中,进程在虚拟地址空间中分配内存,交给硬件的地址都是进程的虚拟地址。然后进程把地址信息给vfio,vfio把进程虚拟地址转换成物理地址给IOMMU,IOMMU在外设给进程虚拟地址搬运数据时把地址转换成这个物理地址。qemu相比ovs-dpdk多了一道手续,guest driver给硬件配置的地址是自己的物理地址,qemu和vfio得把guest的物理地址转换成host的物理地址。

passthrough的问题是虚拟机不能热迁移,热迁移要把网卡pcie空间的数据迁移走,而且还要知道硬件DMA修改了那些guest的内存,要把修改的内存也迁移过去,但硬件都没有提供这样的接口,提供了接口qemu还得有办法获取。既然有其它物理网卡能passthrough了干嘛还要实现virtio物理网卡来passthrough,这样做没什么用。

vdpa

这张图也来自于redhat博客,图太多可能博客作者搞混了图,原图是不对,当时可能想把vpda往vfio/mdev方面靠,首先mdev并不要求必须遵循virtio标准,vdpa实现了数据面的virtio标准,并且把datapath offload到了硬件,控制面没有offload继续由qemu模拟,硬件设备虚拟出来的vdpa未必实现了virtio标准要求的pcie功能,显然用vfio不行,没有vfio就不能利用vfio控制iommu的代码,vdpa需要自己开发,内核中没有upstream,控制面利用vhost协议,vhost再调用vhost-vdpa,vhost-vdpa调用硬件厂商提供的接口把控制信息下放到硬件中。

这种方法硬件网卡直接把包DMA到guest中了,问题是kick和call还是很麻烦,kick到了kvm,kvm通知vhost-vdpa,vhost-vdpa调用硬件驱动通知硬件。硬件call时中断给了硬件驱动,硬件驱动通知vhsot-vdpa,vhost-vdpa通知kvm,kvm把中断注入guest,如果guest用dpdk poll mode driver,kick和call就不成问题了。

搞了这么复杂,第一是为了让硬件网卡实现起来容易,硬件网卡厂商基于SRIOV和Scable IOV实现资源分割,再模拟一下vring操作就可以包装出vdpa。第二是为了实现热迁移,寄希望于硬件厂商的driver能提供接口获取DMA写了那些guest内存。第三guest和host用vdpa统一用virtio-net驱动,qemu只增加一个vhost-vdpa模块,qemu也简单,硬件的不同让硬件厂商的驱动屏蔽,厂商同时提供硬件和驱动,其它模块都不动就能适配不同厂商。

性能分析

guest保持不变,用的都是virtio-net驱动,中断有开销,协议栈有开销,这是避免不了的。定性分析一下三种转发模型的利弊,忽略virtio full offload。首先上限受制于PCIE插槽的物理能力,当然真实场景下很难达到物理上限,只有dpdk l2fwd这些简单模型下才能达到。包处理就是一条流水线,达到无缝配合才能实现性能最高,并行几条流水线处理就更好了。

简单总结一下影响性能的几个因素,分析每种因素在三种模块中的影响。

  • 中断收包有上下文切换,有切换就会有性能开销。

vhost-net在物理网卡收发包用了中断,vhost-user用了dpdk pmd没有中断开销。

  • zero-copy,当然是拷贝越少越好了,最好零拷贝。

vdpa就是zero-copy。vhost-net 和vhost-user rx无法zero-copy,假如rx要实现zero copy,guest alloc skb,backend把skb给了硬件网卡驱动,驱动设置给硬件网卡,硬件哪知道要来的包是给哪个虚拟机,假如硬件网卡一个队列对应一个虚拟机,那guest不提供skb,硬件网卡就丢包了,rx skb只能由硬件网卡驱动分配,分配时能不能从guest内存中分配,好像也不行,没法和guest同步,只能从内核或者ovs空间中分配skb,分配的skb也没法共享给guest,必须拷贝。vhost-net和vhsot-user tx都能实现zero-copy,guest alloc skb,backend直到等物理网卡驱动DMA走再通知guest发送完了,你可以回收skb了,有点麻烦,第一guest可能得等好久才能回收,第二等硬件网卡发送完了通知哪个guest回收难实现。所以vhost-net和vhost-user zero-copy都不现实。

  • hugepage,能减少TBL miss。

vhost-user模型中qemu和ovs-dpdk都用到了hugepage,坏处是内存不能超卖。

  • 多队列。

就是说参与转发的CPU多少,从串行变成并行,当然能提高性能了,但CPU资源是有限的,到底几个队列好呢,物理网卡有多队列,virtio-net也有多队列,按流分队列还是按包分队列,不管怎样进哪个队列由物理网卡来实现,软件实现不划算,物理网卡计算一个hash值写到skb中,到了virtio-net再根据这个值再入virtio-net队列。发送最简单配置就是一个cpu一个队列。

  • 无锁

减少同步的开销,DPDK中有无锁队列,CPU之间传递skb用无锁队列开销就小。另一方面就是查流表和写流表实现无锁,用urcu等等。

  • 接力干还是一口气干到底

pipeline设计问题,接力干就是一个cpu把skb处理一会然后把skb放入队列交由下一下cpu处理,下一个cpu poll还是上个cpu通知下一个cpu开始干活,poll没sbk就白白浪费cpu,通知机制有开销和时延。一口气干到底就是就是一个cpu收skb处理skb最后发送skb,把所有活都干了,多个cpu同时开干,配合多队列好一点。这两种模式的不同涉及到cpu cache/prefech等技术的利用,接力干对cache/prefetch友好。vhost-net是接力干的,vhost-user两个模式都能用,用户态修改代码和调试都容易一点。

vhost-net

vhost-user

vdpa

interrupt

有开销

无开销

无开销

zero-copy

不能用

不能用

没必要用

hugepage

不能用

用了

没必要用

mutilple queue

能用

能用

能用

lock

没有

不存在

pipeline

分工衔接通知复杂CPU不能专心干活

灵活设计,CPU可以独占

不存在

整体来看vdpa是性能最高的,还省cpu,但是价钱贵,性能其次是vhost-user,有点费cpu,vhost性能最差。

总结

vhost-net用的最多,配套完善,稳定成熟。vhost-user据我所知在电信级别云中很常用,电信级别云只追求性能,不考虑超卖,vcpu强绑定,不跨numa,网元数据面passthrough,数据面和控制面通过vhost-user通信。如果数据面用了vhost-user能热迁移能横向扩展,这样更符合NFV的理念,但普通openstack环境vhost-user就不能用内核的功能了,内核qos,netfilter,connection tracking,三层转发和arp都不能用了,意味着openstack安全组,QOS和DVR都没法用了,只能用高性能三层专用网关。vpda个人没用过,没有这样的硬件,可能很多公司已经开始试用了,恐怕是一张很贵的卡,不仅要处理virtio还要处理vxlan,虚拟机能用,裸机也能用。

没有完美的开源技术,只有最佳实践经验,最佳适用场景,用起来,修改起来,回馈开源社区。

参考文献

https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net

https://www.redhat.com/en/blog/journey-vhost-users-realm

https://www.redhat.com/en/blog/how-deep-does-vdpa-rabbit-hole-go

https://zhuanlan.zhihu.com/p/336616452

https://zhuanlan.zhihu.com/p/308114104

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • openstack网络设计-(三)ovs offload

    惠伟:openstack网络设计-(一)试探​zhuanlan.zhihu.com

    惠伟
  • Virtio网络的演化之路

    作为一个开放的标准接口,virtio一直在云计算与虚拟化中扮演着重要的角色。而virtio网络接口,作为virtio标准支持下最复杂的接口之一,在虚拟机/容器网...

    虚拟化云计算
  • ovs vxlan实现代码分析

    接前面这个写起,比较过linux kernel vxlan device和ovs vxlan的性能,很好奇ovs vxlan是怎么实现的,linux kerne...

    惠伟
  • virtio,sriov和host网络性能简单测试对比

    Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz

    惠伟
  • Openstack G版本 Ubuntu13.04三节点实验记录

    本篇文档参考了官网文档(http://docs.openstack.org/),github(https://github.com/mseknibilel/Op...

    三杯水Plus
  • 在虚拟机间NFV应用上使用采用DPDK的Open vSwitch

    概述 数据平面开发套件(DPDK)可提供高性能的数据包处理库和用户空间驱动程序。自Open vSwitch(OVS)2.4版 (http://openvswit...

    SDNLAB
  • vhost-user 简介

    什么是 vhost-user 在 vhost 的方案中,由于 vhost 实现在内核中,guest 与 vhost 的通信,相较于原生的 virtio 方式性能...

    猿大白
  • SDN实战团技术分享(三十八):DPDK助力NFV与云计算

    DPDK最初动机很简单,网络处理器的软件解决方案,证明IA多核处理器能够支撑高性能数据包处理。 什么是DPDK?对于用户来说,它可能是一个出色的包数据处理性能加...

    SDNLAB
  • openstack网络设计-(一)试探

    openstack的api只能扩展并且向前兼容,不能影响已经开发的云管和监控等业务。

    惠伟

扫码关注云+社区

领取腾讯云代金券