OpenVSwitch 硬件加速浅谈

2020-07-01 00:00:00 硬件 规则 网卡 网络 转发

本文SDNLAB。

现代的虚拟化技术使得开发和部署网络服务变得更加简单方便。基于虚拟化的网络服务,具有多样性,低成本,易集成,易管理,低持有成本等优点。而虚拟交换机已经成为了一个高度虚拟化环境不可缺少的一部分。OpenVSwitch是所有虚机交换机中的佼佼者,广泛被各种SDN方案采用。

OpenVSwitch kernel datapath

--

OpenVSwitch是一个实现了OpenFlow的虚拟交换机,它由多个模块组成。主要有位于用户空间的ovsdb-server和ovs-vswitchd进程,和位于内核空间的OVS datapath组成。在一个SDN架构中,Controller将各种网络拓扑,网络功能转换成OVS的数据和OpenFlow规则,分别下发给ovsdb-server和ovs-vswitchd进程,OpenFlow规则可以通过ovs-ofctl dump-flows查看。

网络数据的转发,都是由位于内核空间的OVS datapath完成。用户空间和内核空间的信息是怎么同步的?对于一个网络数据流,个数据包到达OVS datapath,这个时候的datapath没有转发信息,并不知道怎么完成转发。接下来OVS datapath会查询位于用户空间的ovs-vswitchd进程。ovs-vswitchd进程因为有OpenFlow信息,可以根据OpenFlow规则完成match-action操作,也就是从一堆OpenFlow规则里面匹配网络数据包对应的规则,根据这些规则里的action实现转发。

这样个数据包就完成了转发。与此同时,ovs-vswitchd会通过netlink向OVS datapath写入一条(也有可能是多条)转发规则,这里的规则不同于OpenFlow规则,可以通过ovs-dpctl dump-flows查看。这样,同一个网络数据流的后继网络数据包到达OVS datapath时,因为已经有了转发规则,datapath就可以直接完成转发,不再需要向ovs-vswitchd查询。

通过ovs-vswitchd查找OpenFlow实现转发的路径称为slow-path,通过OVS datapath直接转发的路径称为fast-path。OVS的设计思路就是通过slow-path和fast-path的配合使用,完成网络数据的高效转发。这种设计思想类似于传统的硬件网络设备。(经sdnlab的读者提示,这里其实更像fast switching,在此感谢)例如Cisco CEF架构,也是分成了两层,Control Plane存储了当前设备的全部转发信息(RIB),而Data Plane会存储实际的转发信息(FIB)。网络数据的转发在Data Plane完成,当Data Plane没有相应的FIB,会向上查询RIB进而构建FIB。

OpenVSwitch kernel datapath,实际上是在通用的硬件&软件上实现了专用网络设备的功能。优点在开始说过了,但是这种实现也有自己的缺点。

硬件交换机因为有专门的转发硬件,可以保证任意时间都有一定的资源用于转发。但是OVS datapath在操作系统内核空间实现转发,本质上是通过操作系统内的几个进程来完成工作。操作系统会像对待其他进程一样,将CPU的部分时间片,而不是整个CPU分配给虚拟交换机,内存也需要受操作系统的管理,这就存在资源抢占的可能。所以,虚拟交换机并不能保证在需要转发网络数据的时候一定占有资源。

另一方面,因为操作系统本身的设计,需要经过硬中断,软中断,内核空间和用户空间的切换来完成网络数据的传输,通过内核进行转发使得网络数据在操作系统内的路径也很长。

所以现在的共识是,基于内核实现的虚拟交换机,会对网络性能(throughput,latency,PPS等)带来额外的损耗。这是虚拟交换机不可回避的问题。OVS kernel datapath多用于一些对网络性能要求不高的场合。

OpenVSwitch DPDK

--

DPDK(Data Plane Development Kit)本身是个独立的技术,OpenVSwitch在2012年提供了对DPDK的支持。

DPDK的思路是,绕过操作系统内核,在用户空间,通过PMD(Poll Mode Driver)直接操作网卡的接收和发送队列。在网络数据的接收端,PMD会不断的轮询网卡,从网卡上收到数据包之后,会直接通过DMA将其传输到预分配的内存中,同时更新接收队列的指针,这样应用程序很快就能感知收到数据包。DPDK绕过了大部分中断处理和操作系统的内核空间,大大缩短了网络数据在操作系统内的路径长度。

另一方面,因为PMD采用了轮询的方式与网卡交互,DPDK要独占部分CPU和内存,这样在任意时间都有一定的资源用于网络转发,避免了因为操作系统调度带来的资源抢占的问题。

因为DPDK绕过了内核空间,OVS-DPDK的datapath也存在于用户空间,采用如下图所示。对于SDN controller来说,因为连接的是ovs-vswitchd和ovsdb-server,所以感觉不到差异。

DPDK针对主机网络虚拟化的问题,提出了有效的解决方案。基于DPDK的网络方案,能大幅提升网络性能,并且已经在一些对网络性能有要求的场合使用,例如NFV。

不过,虽然DPDK在一定程度上解决了性能的问题,并且DPDK社区在不断的进行优化,但是DPDK也有其自身的问题。首先,DPDK没有集成在操作系统中,使用DPDK就需要额外的安装软件,这增加了维护成本。其次,绕过了Linux内核空间,也就是绕过了网络协议栈,这使得基于DPDK的应用更难调试和优化,因为大量的基于Linux kernel网络调试监控工具在DPDK下不可用了。第三个问题,DPDK独占了部分CPU和内存,这实际上分走了本该用来运行应用程序的资源,直观的感受是,使用了DPDK之后,主机可以部署的虚机数变少了。

OpenVSwitch Hardware offload

--

OpenVSwitch硬件卸载是近几年才提出的方案,到目前为止并不完全成熟。

Linux TC(Traffic Control)Flower

--

要介绍OVS硬件卸载,必须要从TC说起。TC在Linux Kernel 2.2版本开始提出,并在2.4版本(2001年)完成。初的Linux TC是为了实现QoS[1],当然TC现在仍然有QoS的功能。它在netdev设备的入方向和出方向增加了挂载点,进而控制网络流量的速度,延时,优先级等。Linux TC在整个Linux Kernel Datapath中的位置如下图所示:

随后,TC增加了Classifier-Action子系统[2],可以根据网络数据包的报头识别报文,并执行相应的Action。与其他的Classifier-Action系统,例如OpenFlow,不一样的是,TC的CA子系统并不只是提供了一种Classifier(识别器),而是提供了一个插件系统,可以接入任意的Classifier,甚至可以是用户自己定义的Classifier。

在2015年,TC的Classifier-Action子系统增加了对OpenFlow的支持[3],所有的OpenFlow规则都可以映射成TC规则。随后不久,OpenFlow Classifier又被改名为Flower Classifier。这就是TC Flower的来源。

Linux TC Flower hardware offload

--

在2011年,Linux内核增加了基于硬件QoS的支持[4]。因为TC就是Linux内实现QoS的模块,也就是说Linux增加了TC的硬件卸载功能。在2016年,Linux内核又增加了对TC Classifier硬件卸载的支持,但是这个时候只支持了u32类型的Classifier(与TC Flower并列的,但是历史更悠久的一种Classifier)。在4.9~4.14内核,Linux终于增加了对TC Flower硬件卸载的支持。也就是说OpenFlow规则有可能通过TC Flower的硬件卸载能力,在硬件(主要是网卡)中完成转发。

TC Flower硬件卸载的工作原理比较简单。当一条TC Flower规则被添加时,Linux TC会检查这条规则的挂载网卡是否支持并打开了NETIF_F_HW_TC标志位,并且是否实现了ndo_steup_tc(TC硬件卸载的挂载点)。如果都满足的话,这条TC Flower规则会传给网卡的ndo_steup_tc函数,进而下载到网卡内部[5]。

网卡的NETIF_F_HW_TC标志位可以通过ethtool来控制打开关闭:

# ethtool -K eth0 hw-tc-offload on
# ethtool -K eth0 hw-tc-offload off

相关文章