ovn-northd.8: Correct description of sending out inport.
[cascardo/ovs.git] / ovn / ovn-architecture.7.xml
index 0bf9337..318555b 100644 (file)
       A field that denotes the logical datapath through which a packet is being
       processed.
       <!-- Keep the following in sync with MFF_LOG_DATAPATH in
-           ovn/controller/lflow.h. -->
+           ovn/lib/logical-fields.h. -->
       OVN uses the field that OpenFlow 1.1+ simply (and confusingly) calls
       ``metadata'' to store the logical datapath.  (This field is passed across
       tunnels as part of the tunnel key.)
         A field that denotes the logical port from which the packet
         entered the logical datapath.
         <!-- Keep the following in sync with MFF_LOG_INPORT in
-             ovn/controller/lflow.h. -->
+             ovn/lib/logical-fields.h. -->
         OVN stores this in Nicira extension register number 6.
       </p>
 
         leave the logical datapath.  This is initialized to 0 at the
         beginning of the logical ingress pipeline.
         <!-- Keep the following in sync with MFF_LOG_OUTPORT in
-             ovn/controller/lflow.h. -->
+             ovn/lib/logical-fields.h. -->
         OVN stores this in Nicira extension register number 7.
       </p>
 
         egress port are the same.
       </p>
 
+      <p>
+        Logical patch ports are a special case.  Logical patch ports do not
+        have a physical location and effectively reside on every hypervisor.
+        Thus, flow table 33, for output to ports on the local hypervisor,
+        naturally implements output to unicast logical patch ports too.
+        However, applying the same logic to a logical patch port that is part
+        of a logical multicast group yields packet duplication, because each
+        hypervisor that contains a logical port in the multicast group will
+        also output the packet to the logical patch port.  Thus, multicast
+        groups implement output to logical patch ports in table 32.
+      </p>
+
       <p>
         Each flow in table 32 matches on a logical output port for unicast or
         multicast logical ports that include a logical port on a remote
 
       <p>
         Flows in table 33 resemble those in table 32 but for logical ports that
-        reside locally rather than remotely.  (This includes logical patch
-        ports, which do not have a physical location and effectively reside on
-        every hypervisor.)  For unicast logical output ports
+        reside locally rather than remotely.  For unicast logical output ports
         on the local hypervisor, the actions just resubmit to table 34.  For
         multicast output ports that include one or more logical ports on the
         local hypervisor, for each such logical port <var>P</var>, the actions