1. 逻辑关系
ovs的openflow协议流表主要包括table=id、匹配数据包相关项、匹配优先级条件等，满足匹配条件后，才会触发相应的处理动作，如转发、丢弃、修改数据包等。动作可以是必备的（如丢弃），也可以是可选的（如转发到特定端口）。那么OVN通过逻辑流表构建openflow流表还包括使用了一些openflow寄存器，用于存储如tunnel_key和输入、输出端口等。最主要的是如ovs 的reg14存储了入端口，reg15记录了输出的端口，以及metadata记录了tunnel_key信息，确定了该流表属于ovn的哪个的datapath结构。
2. OVN的tunnel_key信息
tunnel_key信息是属于ovn里面存储信息，该信息绑定了logic switch或者logic route，可以通过ovn-sbctl list Datapath_Binding或ovn-sbctl find Datapath_Binding 获取。确定逻辑路由器/逻辑交换机和tunnel_key一一对应关系，且该key的值会封装在geneve协议中，作为租户的隔离。
3.OVN 的logical_port信息
ovn-nbctl show dp-xxx，可以发现该dp-xxx下的所有逻辑端口，ip和mac信息等。ovn-sbctl lflow-list dp-xx可以查看该dp下的所有逻辑流表。ovn-sbctl find Port_Binding可以查看详细的逻辑端口的信息，里面有包含的tunnel_key信息，确定是哪个端口Datapath_Binding。
4. ovs物理端口
ovs连接的虚拟机/容器的接口，通过ovs-vsctl find interface name=interface名和ovs-vsctl find port name=port名可以查看端口的详细情况。例如下图所示：主要的信息包括mac地址、openflow协议的端口，external_ids里面存储的一些补充信息，可以确定该port属于哪个容器/虚拟机，以及iface id，那么逻辑端口也即能唯一确定。
5. 物理转逻辑
ovs table 0表实现了物理转逻辑，如匹配in_port=263输入的的流量，根据port和interface关系，load对应的metadata， reg信息，主要将inport输入到对应的逻辑流表中，即要转到逻辑上对应的哪个datapatch上，如第一条load 0x14 ->reg14存储该物理的in_port的端口对应的逻辑端口映射，load 0x15c ->存放了改逻辑datapatch的tunnel_key。
6. pipeline转发
ovs openflow pipeline和logic swich pipeline主要的对应的关系， 同个dp，同一个metadata匹配项中处理。例如以logical_switch为例子:
| logical switch | ovs openflow pipeline |
| 物理转逻辑 | table =0 next table 8 |
|
table=0 Admission Control and Ingress Port Security - ls_in_port_sec_l2（端口和mac地址检查） |
table=8 next table 9 |
|
Table 1: Ingress Port Security（mac地址对应ip检查）ls_in_port_sec_ip |
table=9 next table 10 |
|
Ingress Table 2: Ingress Port Security - Neighbor discovery ls_in_port_sec_nd arp和nd处理 |
table=10 next table 11 |
|
Ingress Table 3:from-lportPre-ACLs (ls_in_pre_acl )This table prepares flows for possible stateful ACL processing in ingress table ACLs |
table=11 next table=12 |
| ......... | ....... |
| 转输出表 | table 32 转远端隧道输出, table 33 本端输出到logical output table |
|
Egress Table 0: Pre-LB ls_out_pre_lb |
table=40 |
|
Egress Table 1:to-lportPre-ACLs ......... |
table=41
................ |
|
Egress Table 4:to-lportACLs ls_out_acl |
table=44 |
|
................. |
...................... |
|
最终处理1-转到其他pipeline处理 最终处理2-逻辑转物理 |
可能转其他pipeline继续处理。如子网路由，vpc路由后转子网等。 table=65 输出到物理 |
table32 ,table=33 的转输出表如
cookie=0xb35d66b6, duration=2.271s, table=32, n_packets=0, n_bytes=0, idle_age=2, priority=100,reg15=0x2135,metadata=0x3 actions=load:0x3->NXM_NX_TUN_ID[0
..23],set_field:0x2135->tun_metadata0,move:NXM_NX_REG14[0..14]->NXM_NX_TUN_METADATA0[16..30],output:4 封禁dp和输入端口信息，输出到隧道口->对端table 0入口
cookie=0x0, duration=24.992s, table=0, n_packets=5, n_bytes=422, idle_age=1, priority=100,in_port=25 actions=move:NXM_NX_TUN_ID[0..23]->OXM_OF_METADATA[0.
.23],move:NXM_NX_TUN_METADATA0[16..30]->NXM_NX_REG14[0..14],move:NXM_NX_TUN_METADATA0[0..15]->NXM_NX_REG15[0..15],resubmit(,33) 转table = 33 继续转输出表
对应的ovn代码中的定义：
logical_route同样的流程pipeline编排，只是pipeline功能实现不一样，具体参考 ovn-northd文档详细描述了ovn pipeline表的作用。
8. 互查openflow流表找到对应的ovn logical_flow流表
1. 查找datapatch
那么对应的tunkey 3 ,metadata =3的openflow流表属于这个dp.
2. 通过ovn-sbctl list Logical_Flow 查找datapath对应的logical_flow， 在ovs中，根据上面的映射关系可以在table表中，找该metadata的流表，并根据cookie的值等于__uuid的前32位来定位到具体的流表。
可看到对应的openflow信息对应。
