1、ovs-vswitchd组件是交换机的主要模块，运行在用户态，其主要负责基本的转发逻辑、地址学习、外部物理端口绑定等。还可以运用OVS自带的ovs-ofctl工具采用openflow协议对交换机进行远程配置和管理。
2、ovsdb-server组件是存储OVS的网桥等配置、日志以及状态的轻量级数据库。它与ovs-vswitchd都是以一个单独的进程存在于系统中。ovsdb是一个可提供持久化存储的数据库，可借助ovs-vsctl工具配置OVS交换机，配置信息将保存在ovsdb中，设备重启后，相关OVS配置不会丢失。ovs-vswitchd组件与ovsdb-server组件间的通信采用OVSDB管理协议，通信内容包括加载配置信息，同时将运行过程中变化的OVS的配置信息保存到数据库中。
3、openvswitch.ko组件运行在内核态，属于快速转发平面，主要负责流表匹配、报文修改、隧道封装、转发或者上送，并且维护底层转发表。在原始OVS中，报文首先经过该组件完成报文解析和封装、转发规则匹配，若找到转发规则不再经过用户空间，直接转发。否则转交用户空间的ovs-vswitchd组件进行处理。ovs-vswitchd组件与openvswitch.ko组件之间采用netlink执行进程间的通信。netlink是一种进程间通信机制，可用于处理用户态和内核态的通信。
自定义driver
https://github.com/reachsrirams/packt-openstack-networking-cookbook/tree/master/Chapter12
vSwitch的早期代表是Linuxbridge，它在设计之初就是为了提供基本的网络连接，因此它只是模拟了ToR交换机的行为，并将自己接入到现有的物理网络中。这样实现的优点是，现有物理网络的理论和协议可以直接套用，不需要重复设计。缺点就是，作为物理网络的延伸，使得虚拟workload的网络与物理网络紧耦合，影响了虚拟化本身带来的诸如灵活，快速上线的优势。
TOR（Top of Rack）是一种数据中心的布线方式。架顶式接线方式，是EOR/MOR方式的扩展。
随着网络虚拟化（network virtualization）的出现，为连接虚拟workload的网络提供了另一种可能。物理网络仍然由物理网络设备管理，虚拟workload的网络，单独由vSwitch管理，并且在现有物理网络（underlay）基础之上，再定义一个独立的overlay网络（例如VxLAN）。这个overlay网络不受物理网络设备控制，完全由vSwitch控制。
OVS
OpenVSwitch就是基于这个设计思想实现的。OpenVSwitch是一个多层的，开源虚拟交换机。不过到目前为止，LinuxBridge也支持了VxLAN，OpenVSwitch也能够支持对应于物理网络的VLAN，FLAT网络。
OpenVSwitch，不论是用户空间的ovs-vswitchd，还是内核空间的kernel datapath，最核心都是要实现一个查找算法。
OpenVSwitch实现了一个统一的查找算法：TSS（Tuple Space Search），这本质上是一个hash查找算法。
Table中查找OpenFlow规则。对于kernel datapath，也需要根据网络数据包的特征，从cache中查找datapath actions。
当一个网络连接的第一个网络数据包（首包）被发出时，OVS内核模块会先收到这个packet。
但是内核模块现在还不知道如何处理这个包，因为所有的OpenFlow都存在ovs-vswitchd，因此它的默认行为是将这个包上送到ovs-vswitchd。
ovs-vswitchd通过OpenFlow pipeline，处理完网络数据包送回给OVS内核模块，同时，ovs-vswitchd还会生成一串类似于OpenFlow Action，实现更简单的datapath action。这串datapath action会一起送到OVS内核模块。
因为同一个网络连接的所有网络数据包特征（IP，MAC，端口号）都一样，当OVS内核模块收到其他网络包的时候，可以直接应用datapath action。
因此，这里将OVS内核模块与OpenFlow协议解耦了，OpenFlow的小改动影响不到内核模块。
4>—
ovs为了提高效率，数据包会先在内核层datapath进行流表项匹配处理，对于匹配失败，或者是匹配到表项的action为发向用户层时，才会去用户层继续查找匹配。对于在用户层匹配成功的数据包会按照表项action相应处理，并向内核层下发一条匹配到的表项，方便以后类似数据包直接在内核层完成匹配转发。当没有找到匹配的流表时，内核通过netlink 发送报文到用户层处理
在用户态，有线程监听消息，一旦有消息，则触发udpif_upcall_handler进行处理
action是一组流表操作，是C或C++实现的,action类型如下
OVS内核模块早期基于名为microflow的cache。microflow也是基于Match-Action而实现
Match包含了所有OpenFlow可能的匹配的值，也就是2-4层包头和一些metadata。
OpenFlow Table
从OpenVSwitch的角度来说，OpenFlow的管理是简单的。因为OpenFlow是由SDN controller管理，OpenVSwitch只是提供了OpenFlow增删改查的接口。
ovs-vsctl： 查询和更新ovs-vswitchd的配置
ovs-ofctl： 查询和控制OpenFlow交换机和控制器
root@compute1:/var/lib/nova# ovs-vsctl show
205a13a2-1ad6-4ae0-8c84-abed97444aa9
Bridge br-int //OVS integration 桥 br-int
fail_mode: secure
Port "qvo37b25c08-e8" //端口，用来连接一个虚机网卡的TAP设备所连接的linux bridge
tag: 1
Interface "qvo37b25c08-e8"
Port patch-tun //端口，用来连接桥br-tun
Interface patch-tun
type: patch
options: {peer=patch-int} //和桥 br-tun上的patch-int是对等端口
Port br-int
Interface br-int
type: internal
Port "qvo155845ae-5e" //端口，用来连接另一个虚机网卡的TAP设备所连接的linux bridge
tag: 1
Interface "qvo155845ae-5e"
Bridge br-tun //OVS Tunnel 桥br-tun
Port br-tun
Interface br-tun
type: internal
Port patch-int //端口patch-int，用来连接桥br-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a000115" //端口，连接GRE Tunnel
Interface "gre-0a000115"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"}
ovs_version: "2.0.2" //GRE Tunnel是点到点之间建立的，这头的IP为10.0.1.31，那头的IP地址为 10.0.1.21
root@compute1:/var/lib/nova# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000f6b428614747
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
1(patch-int): addr:3e:7b:d5:fa:26:8d //端口 patch-int的ID 是 1
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
2(gre-0a000115): addr:2a:26:b2:99:f3:5a //端口 gre-0a000115的ID 是 2
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
LOCAL(br-tun): addr:f6:b4:28:61:47:47
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
OpenStack使用Linux TAP设备上的iptables来实现Security Group规则，而OVS不支持直接和br-int桥相连的TAP设备上的iptables。
通过查看虚机的libvirt XML定义文件 /var/lib/nova/instances//libvirt.xml可以看出来虚机所连接的TAP设备：
<interface type="bridge">
<mac address="fa:16:3e:fe:c7:87"/> //
<source bridge="qbr37b25c08-e8"/> //虚机TAP设备所挂接的linux bridge
<target dev="tap37b25c08-e8” /> //虚机所连接的interface
</interface>
Neutron使用TAP设备的iptables来实现Security groups
查看第一个虚机的TAP设备上的iptables：
root@compute1:/var/lib/nova# iptables -S | grep tap37b25c08-e8
-A neutron-openvswi-FORWARD -m physdev --physdev-out tap37b25c08-e8 --physdev-is-bridged -j neutron-openvswi-sg-chain
-A neutron-openvswi-FORWARD -m physdev --physdev-in tap37b25c08-e8 --physdev-is-bridged -j neutron-openvswi-sg-chain
-A neutron-openvswi-INPUT -m physdev --physdev-in tap37b25c08-e8 --physdev-is-bridged -j neutron-openvswi-o37b25c08-e
-A neutron-openvswi-sg-chain -m physdev --physdev-out tap37b25c08-e8 --physdev-is-bridged -j neutron-openvswi-i37b25c08-e
-A neutron-openvswi-sg-chain -m physdev --physdev-in tap37b25c08-e8 --physdev-is-bridged -j neutron-openvswi-o37b25c08-e
OpenStack Mitaka 版本已全面支持 OVS 使用 DPDK 提升网络交换性能
安装参考：https://www.jianshu.com/p/c84421b9a3dd
DPDK平台提供的接口库，可以将底层环境资源做抽象，即在系统中新增了环境抽象层（EAL），将网卡驱动在用户态实现，系统只需在网卡初始化时设置网卡驱动接口即可将网卡收到的报文直接交给用户空间进程进行处理，网卡发送报文时也通过调用用户态定义的发送报文接口将报文直接发送到对应网卡。在OVS的vswitchd进程中新起一个数据收发接管线程（TO-Thread）用于接管系统的OVS中由datapath执行的数据包接收和发送的功能。数据包的流表匹配则直接进行用户态流表匹配。
OVS+DPDK接收报文处理机制： 当报文到达网卡，EAL层根据网卡初始化和驱动层初始化中绑定的用户态网卡驱动，将报文发送到用户空间交给TO-Thread线程进行接管，在该线程中将进行报文的解析、与内核协议栈通信和获取报文key值的操作，然后在vswitchd进程中凭借报文key值完成用户态流表匹配。用户态流表匹配的操作与传统的OVS一样，但若命中流表项本系统将直接交由TO-Thread线程进行action处理，最终将报文通过该接管线程转发出去或丢弃。接收报文的过程中不经过OVS中内核态的datapath进程的处理和内核态流表的匹配。
OVS+DPDK发送报文处理机制： 发送报文时，先经过协议栈的封装处理，将封装好的报文匹配用户态流表，获取action操作。若为隧道转发则还需进行隧道头封装，将报文发往对应的VTEP端口。在隧道转发过程中可能涉及OVS中内部端口多次转发，并在相应端口做报文处理，报文最终要发出的端口通过流表匹配获得。TO-Thread线程将报文直接发往OVS出端口绑定的网卡，由网卡发送到网络中。
下面是不同的数据路径可以实现的功能：
Userspace： 也称为DPDK，dpif-netdev 或者dummy datapath。这是NetBSD，FreeBSD 和Mac OSX 仅支持的数据路径。
