In userspace, if the tables lookup of the first bridge results in an action of output to a patch port, then it should lookup the bridge of the peer port consequently. The flow installed to datapath will be the final actions combining all the results.
E.g. port_A --- br1 --- port_B (patch) ........ port_C (patch) --- br2 --- port_D flow in br1: in_port=port_A actions=output(port_B) flow in br2: in_port=port_C actions=output(port_D) Then a packet from port_A will be output to port_D, and the datapath flow is simply: in_port(port_A),action:port_D I.e. patch ports are short-cutted in datapath. Ben, please correct me if this not accurate. Han On Tue, Sep 15, 2015 at 6:06 PM, openvswitcher <openvswitc...@163.com> wrote: > Thank you very much. > Could you tell me more details about this? > > I know the packet will be transfer to userspace if flow-miss happens and > flow will be installed to kernel > if the packet matches the openflow-table in openflow switch. > So if one patch port exists between two bridges, how the flow will be > installed in kernel if the patch port is used to connect two bridge? > Will the packet be searched in the userspace within the openflow-tables in > the two bridges and then one final flow be installed in > kernel, or will be searched independently in the openflow-tables of the > different bridges? > > Looking forward for your reply. Thanks. > > > > > > At 2015-09-16 01:26:32, "Han Zhou" <zhou...@gmail.com> wrote: >>Patch port is like a wormhole, which transfers packets between bridges >>transparently. There is no datapath port for it. >>In your case, the packet should be forwarded to br-tun, but it seems >>you have no tunnel port (vxlan, geneve, stt, etc.) in br-tun, so you >>didn't see any output on that bridge. You might wonder why packet is >>not flooded to the internal port br-tun. I assume you use devstack, >>br-tun works in secure mode and there is no "NORMAL" flow (check >>ovs-ofctl dump-flows br-tun), so packet is not flooded there. >> >>Best regards, >>Han >> >>On Tue, Sep 15, 2015 at 12:33 AM, openvswitcher <openvswitc...@163.com> >> wrote: >>> I want to ask one question about patch port and flooding. >>> >>> >>> The topology used is below: >>> >>> >>> namespace 1(tap516ed44b-29) --br-int--br-tun >>> >>> >>> I ping an unreachable address 192.168.10.20 from 192.168.10.2(namespace >>> port tap516ed44b-29),so the arp flow is installed in kernel. >>> But the action is "push_vlan(vid=2,pcp=0),1,pop_vlan,11,13". >>> >>> >>> I wonder why the patch port is not flooded to? >>> >>> >>> The details is bellow: >>> >>> >>> # ovs-dpctl dump-flows >>> >>> skb_priority(0),in_port(9),eth(src=fa:16:3e:49:a8:9b,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.10.2/255.255.255.255,tip=192.168.10.20/255.255.255.255,op=1/0xff,sha=fa:16:3e:49:a8:9b/00:00:00:00:00:00,tha=00:00:00:00:00:00/00:00:00:00:00:00), >>> packets:1970, bytes:82740, used:0.676s, >>> actions:push_vlan(vid=2,pcp=0),1,pop_vlan,11,13 >>> # ovs-appctl dpif/show >>> system@ovs-system: >>> (...skip...) >>> br-ext: hit:103 missed:57 >>> br-ext 65534/2: (internal) >>> fg-d77a2710-06 9/15: (internal) >>> qg-f74784b2-af 1/8: (internal) >>> br-int: hit:299017 missed:223582 >>> br-int 65534/1: (internal) >>> patch-tun 1/none: (patch: peer=patch-int) >>> qr-1be06b4b-0f 3/6: (internal) >>> qr-1f535556-59 4/7: (internal) >>> qr-20f37e1a-13 9/13: (internal) >>> qr-b9961ff6-d8 11/14: (internal) >>> qvo2f01594b-3d 7/11: (system) >>> qvo86dc14d8-61 8/12: (system) >>> tap516ed44b-29 5/9: (internal) >>> tap765e9497-63 6/10: (internal) >>> tap9d8f5064-21 2/5: (internal) >>> br-mgmt0: hit:0 missed:0 >>> br-mgmt0 65534/3: (internal) >>> phy-br-mgmt0 1/none: (patch: peer=int-br-mgmt0) >>> br-tun: hit:4 missed:3 >>> br-tun 65534/4: (internal) >>> patch-int 1/none: (patch: peer=patch-tun) >>> >>> >>> Is the patch port special? >>> >>> _______________________________________________ >>> dev mailing list >>> dev@openvswitch.org >>> http://openvswitch.org/mailman/listinfo/dev > > > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
