注：本文是参照了一些其他文章，原文地址点击这里。

简介

OpenvSwitch不了解的自己找资料了解下，这里不赘述。我们这里简单介绍一下Native OVS和OVS-DPDK的差异。

Native OVS

Native OVS是通过内核空间的datapath转发数据包，kernel datapath(我们可以称为fastpath)包含了对接收报文的转发和操作规则的简单流表。如果报文在fastpath没有匹配到流表，则它会被发送到用户态守护进程去处理(我们可以称为slowpath)。用户态处理完第一个报文之后，会更新fastpath的流表，方便接下来的报文直接进行转发，而不发送到用户态。

OVS-DPDK

DPDK我们这里也不赘述，自己了解下。因为DPDK绕过了kernel，所以我们上面提到的fastpath也会处于用户态，得益于DPDK的优化，这里的转发性能是吊打上面的fastpath，另外就是报文在fastpath不匹配的情况下，进入slowpath也不需要涉及到netlink将报文从内核到用户态传输的开销，而是直接查找slowpath的流表。这里可以理解为fastpath其实就是slowpath的缓存流表。下图简单展示了区别：

上面的图我们可以看到主要是fastpath的区别，接下来我们再展开介绍一下，首先我们可以介绍一下DPDK对网络设备的加速，这里我们经常会遇到的有两类，分别是物理接口(DPDK的librte_eth库处理)、虚拟接口(librte_vhost和librte_ring)，用来连接物理网卡和虚拟机。

Dpif-netdev实现用户态转发，ofproto是OVS实现OpenFlow协议交换机的库，他通过网络与OpenFlow Controller通信，得到slowpath的流表，从而实现对报文转发的控制。ovsdb server维护了OVS的端口等拓扑信息。下图简单列出了各个模块协作的关系图：

流表层次

从物理或虚拟接口接收的报文，基于其报头字段计算出唯一标识符或hash，然后将其与三个转发表的流表匹配：EMC(exact match cache，我们上面提到的fastpath)，dpcls(data path classifier，我们上面提到的slowpath)和ofproto classifier(controller)。 报文的标识符将依次遍历这三个表，直到找到匹配。在这种情况下，将执行由表中的匹配规则指示的action，并且在完成所有动作后将报文转发出ovs，看下图：

以上的三个转发表在吞吐和时延等特性上还是有很大不同的。EMC支持较少数量的流表，但是转发速率最快。报文的必须与五元组的所有字段都匹配，否则会传递给dpcls，dpcls支持更多的流表，并且支持了通配符，此时的吞吐量只有EMC的一半。dpcls的流表匹配后会生成精确流表存入EMC。dpcls如果依然不匹配报文，则会发送到ofproto classifier，让OpenFlow Controller来决定报文的命运，这个路径的性能最低，比EMC慢10倍。当然也会下发流表到dpcls。

OVS-DPDK特性和性能

• DPDK support for v16.07 (supported version increments with each new DPDK release)
• vHost user support
• vHost reconnect
• vHost multiqueue
• Native tunneling support: VxLAN, GRE, Geneve
• VLAN support
• MPLS support
• Ingress/egress QoS policing
• Jumbo frame support
• Connection tracking
• Statistics: DPDK vHost and extended DPDK stats
• Debug: DPDK pdump support
• Link bonding
• Link status
• VFIO support
• ODL/OpenStack detection of DPDK ports
• vHost user NUMA awareness

为了对比一下Native OVS和OVS-DPDK的性能差距，我们用Phy-OVS-Phy的测试方案(数据来源)，可以得出OVS-DPDK的性能大概是Native OVS的10倍，下图展示一下结果：