On Fri, Sep 24, 2021 at 6:52 AM Xavier Simonart <xsimo...@redhat.com> wrote:
>
> Openflow tables OFTABLE_REMOTE_OUTPUT, OFTABLE_LOCAL_OUTPUT
> and OFTABLE_CHECK_LOOPBACK numbering changed, but documentation
> was not updated.
>
> Fixes: dd94f1266c ("northd: MAC learning: Add logical flows for fdb.")
>
> Signed-off-by: Xavier Simonart <xsimo...@redhat.com>
Thanks. Applied.
Numan
> ---
> controller/physical.c | 40 ++++++++++++------------
> ovn-architecture.7.xml | 70 +++++++++++++++++++++---------------------
> 2 files changed, 55 insertions(+), 55 deletions(-)
>
> diff --git a/controller/physical.c b/controller/physical.c
> index 0cfb158c8..c5effe521 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -955,12 +955,12 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> || ha_chassis_group_is_active(binding->ha_chassis_group,
> active_tunnels, chassis))) {
>
> - /* Table 33, priority 100.
> + /* Table 38, priority 100.
> * =======================
> *
> * Implements output to local hypervisor. Each flow matches a
> * logical output port on the local hypervisor, and resubmits to
> - * table 34. For ports of type "chassisredirect", the logical
> + * table 39. For ports of type "chassisredirect", the logical
> * output port is changed from the "chassisredirect" port to the
> * underlying distributed port. */
>
> @@ -1007,7 +1007,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> put_load(zone_ids.snat, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
> }
>
> - /* Resubmit to table 34. */
> + /* Resubmit to table 39. */
> put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> }
>
> @@ -1312,7 +1312,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
>
> } else if (!tun && !is_ha_remote) {
> /* Remote port connected by localnet port */
> - /* Table 33, priority 100.
> + /* Table 38, priority 100.
> * =======================
> *
> * Implements switching to localnet port. Each flow matches a
> @@ -1329,7 +1329,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
>
> put_load(localnet_port->tunnel_key, MFF_LOG_OUTPORT, 0, 32,
> ofpacts_p);
>
> - /* Resubmit to table 33. */
> + /* Resubmit to table 38. */
> put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p);
> ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100,
> binding->header_.uuid.parts[0],
> @@ -1341,7 +1341,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
>
> /* Remote port connected by tunnel */
>
> - /* Table 32, priority 100.
> + /* Table 38, priority 100.
> * =======================
> *
> * Handles traffic that needs to be sent to a remote hypervisor.
> Each
> @@ -1469,7 +1469,7 @@ consider_mc_group(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> }
> }
>
> - /* Table 33, priority 100.
> + /* Table 38, priority 100.
> * =======================
> *
> * Handle output to the local logical ports in the multicast group, if
> @@ -1485,7 +1485,7 @@ consider_mc_group(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> &match, &ofpacts, &mc->header_.uuid);
> }
>
> - /* Table 32, priority 100.
> + /* Table 37, priority 100.
> * =======================
> *
> * Handle output to the remote chassis in the multicast group, if
> @@ -1635,7 +1635,7 @@ physical_run(struct physical_ctx *p_ctx,
> p_ctx->chassis, flow_table, &ofpacts);
> }
>
> - /* Handle output to multicast groups, in tables 32 and 33. */
> + /* Handle output to multicast groups, in tables 37 and 38. */
> const struct sbrec_multicast_group *mc;
> SBREC_MULTICAST_GROUP_TABLE_FOR_EACH (mc, p_ctx->mc_group_table) {
> consider_mc_group(p_ctx->sbrec_port_binding_by_name,
> @@ -1656,7 +1656,7 @@ physical_run(struct physical_ctx *p_ctx,
> * encapsulations have metadata about the ingress and egress logical
> ports.
> * VXLAN encapsulations have metadata about the egress logical port only.
> * We set MFF_LOG_DATAPATH, MFF_LOG_INPORT, and MFF_LOG_OUTPORT from the
> - * tunnel key data where possible, then resubmit to table 33 to handle
> + * tunnel key data where possible, then resubmit to table 38 to handle
> * packets to the local hypervisor. */
> struct chassis_tunnel *tun;
> HMAP_FOR_EACH (tun, hmap_node, p_ctx->chassis_tunnels) {
> @@ -1730,12 +1730,12 @@ physical_run(struct physical_ctx *p_ctx,
> }
> }
>
> - /* Table 32, priority 150.
> + /* Table 37, priority 150.
> * =======================
> *
> * Handles packets received from a VXLAN tunnel which get resubmitted to
> * OFTABLE_LOG_INGRESS_PIPELINE due to lack of needed metadata in VXLAN,
> - * explicitly skip sending back out any tunnels and resubmit to table 33
> + * explicitly skip sending back out any tunnels and resubmit to table 38
> * for local delivery.
> */
> struct match match;
> @@ -1743,13 +1743,13 @@ physical_run(struct physical_ctx *p_ctx,
> match_set_reg_masked(&match, MFF_LOG_FLAGS - MFF_REG0,
> MLF_RCV_FROM_RAMP, MLF_RCV_FROM_RAMP);
>
> - /* Resubmit to table 33. */
> + /* Resubmit to table 38. */
> ofpbuf_clear(&ofpacts);
> put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts);
> ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0,
> &match, &ofpacts, hc_uuid);
>
> - /* Table 32, priority 150.
> + /* Table 37, priority 150.
> * =======================
> *
> * Packets that should not be sent to other hypervisors.
> @@ -1757,19 +1757,19 @@ physical_run(struct physical_ctx *p_ctx,
> match_init_catchall(&match);
> match_set_reg_masked(&match, MFF_LOG_FLAGS - MFF_REG0,
> MLF_LOCAL_ONLY, MLF_LOCAL_ONLY);
> - /* Resubmit to table 33. */
> + /* Resubmit to table 38. */
> ofpbuf_clear(&ofpacts);
> put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts);
> ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0,
> &match, &ofpacts, hc_uuid);
>
> - /* Table 32, priority 150.
> + /* Table 37, priority 150.
> * =======================
> *
> * Handles packets received from ports of type "localport". These ports
> * are present on every hypervisor. Traffic that originates at one
> should
> * never go over a tunnel to a remote hypervisor, so resubmit them to
> table
> - * 33 for local delivery. */
> + * 38 for local delivery. */
> match_init_catchall(&match);
> ofpbuf_clear(&ofpacts);
> put_resubmit(OFTABLE_LOCAL_OUTPUT, &ofpacts);
> @@ -1789,7 +1789,7 @@ physical_run(struct physical_ctx *p_ctx,
> }
> }
>
> - /* Table 32, Priority 0.
> + /* Table 37, Priority 0.
> * =======================
> *
> * Resubmit packets that are not directed at tunnels or part of a
> @@ -1800,11 +1800,11 @@ physical_run(struct physical_ctx *p_ctx,
> ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 0, 0, &match,
> &ofpacts, hc_uuid);
>
> - /* Table 34, Priority 0.
> + /* Table 39, Priority 0.
> * =======================
> *
> * Resubmit packets that don't output to the ingress port (already
> checked
> - * in table 33) to the logical egress pipeline, clearing the logical
> + * in table 38) to the logical egress pipeline, clearing the logical
> * registers (for consistent behavior with packets that get tunneled). */
> match_init_catchall(&match);
> ofpbuf_clear(&ofpacts);
> diff --git a/ovn-architecture.7.xml b/ovn-architecture.7.xml
> index 3d2910358..c2eb3c2cc 100644
> --- a/ovn-architecture.7.xml
> +++ b/ovn-architecture.7.xml
> @@ -1224,8 +1224,8 @@
> output port field, and since they do not carry a logical output port
> field in the tunnel key, when a packet is received from ramp switch
> VXLAN tunnel by an OVN hypervisor, the packet is resubmitted to
> table 8
> - to determine the output port(s); when the packet reaches table 32,
> - these packets are resubmitted to table 33 for local delivery by
> + to determine the output port(s); when the packet reaches table 37,
> + these packets are resubmitted to table 38 for local delivery by
> checking a MLF_RCV_FROM_RAMP flag, which is set when the packet
> arrives from a ramp tunnel.
> </p>
> @@ -1364,9 +1364,9 @@
> <dl>
> <dt><code>output:</code></dt>
> <dd>
> - Implemented by resubmitting the packet to table 32. If the
> pipeline
> + Implemented by resubmitting the packet to table 37. If the
> pipeline
> executes more than one <code>output</code> action, then each one is
> - separately resubmitted to table 32. This can be used to send
> + separately resubmitted to table 37. This can be used to send
> multiple copies of the packet to multiple ports. (If the packet
> was
> not modified between the <code>output</code> actions, and some of
> the
> copies are destined to the same hypervisor, then using a logical
> @@ -1430,38 +1430,38 @@
>
> <li>
> <p>
> - OpenFlow tables 32 through 47 implement the <code>output</code>
> action
> - in the logical ingress pipeline. Specifically, table 32 handles
> - packets to remote hypervisors, table 33 handles packets to the local
> - hypervisor, and table 34 checks whether packets whose logical ingress
> + OpenFlow tables 37 through 39 implement the <code>output</code>
> action
> + in the logical ingress pipeline. Specifically, table 37 handles
> + packets to remote hypervisors, table 38 handles packets to the local
> + hypervisor, and table 39 checks whether packets whose logical ingress
> and egress port are the same should be discarded.
> </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,
> + Thus, flow table 38, 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.
> + groups implement output to logical patch ports in table 37.
> </p>
>
> <p>
> - Each flow in table 32 matches on a logical output port for unicast or
> + Each flow in table 37 matches on a logical output port for unicast or
> multicast logical ports that include a logical port on a remote
> hypervisor. Each flow's actions implement sending a packet to the
> port
> it matches. For unicast logical output ports on remote hypervisors,
> the actions set the tunnel key to the correct value, then send the
> packet on the tunnel port to the correct hypervisor. (When the
> remote
> hypervisor receives the packet, table 0 there will recognize it as a
> - tunneled packet and pass it along to table 33.) For multicast
> logical
> + tunneled packet and pass it along to table 38.) For multicast
> logical
> output ports, the actions send one copy of the packet to each remote
> hypervisor, in the same way as for unicast destinations. If a
> multicast group includes a logical port or ports on the local
> - hypervisor, then its actions also resubmit to table 33. Table 32
> also
> + hypervisor, then its actions also resubmit to table 38. Table 37
> also
> includes:
> </p>
>
> @@ -1469,7 +1469,7 @@
> <li>
> A higher-priority rule to match packets received from ramp switch
> tunnels, based on flag MLF_RCV_FROM_RAMP, and resubmit these
> packets
> - to table 33 for local delivery. Packets received from ramp switch
> + to table 38 for local delivery. Packets received from ramp switch
> tunnels reach here because of a lack of logical output port field
> in
> the tunnel key and thus these packets needed to be submitted to
> table
> 8 to determine the output port.
> @@ -1477,7 +1477,7 @@
> <li>
> A higher-priority rule to match packets received from ports of type
> <code>localport</code>, based on the logical input port, and
> resubmit
> - these packets to table 33 for local delivery. Ports of type
> + these packets to table 38 for local delivery. Ports of type
> <code>localport</code> exist on every hypervisor and by definition
> their traffic should never go out through a tunnel.
> </li>
> @@ -1492,32 +1492,32 @@
> packets, the packets only need to be delivered to local ports.
> </li>
> <li>
> - A fallback flow that resubmits to table 33 if there is no other
> + A fallback flow that resubmits to table 38 if there is no other
> match.
> </li>
> </ul>
>
> <p>
> - Flows in table 33 resemble those in table 32 but for logical ports
> that
> + Flows in table 38 resemble those in table 37 but for logical ports
> that
> reside locally rather than remotely. For unicast logical output
> ports
> - on the local hypervisor, the actions just resubmit to table 34. For
> + on the local hypervisor, the actions just resubmit to table 39. 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
> change the logical output port to <var>P</var>, then resubmit to
> table
> - 34.
> + 39.
> </p>
>
> <p>
> A special case is that when a localnet port exists on the datapath,
> remote port is connected by switching to the localnet port. In this
> - case, instead of adding a flow in table 32 to reach the remote port,
> a
> - flow is added in table 33 to switch the logical outport to the
> localnet
> - port, and resubmit to table 33 as if it were unicasted to a logical
> + case, instead of adding a flow in table 37 to reach the remote port,
> a
> + flow is added in table 38 to switch the logical outport to the
> localnet
> + port, and resubmit to table 38 as if it were unicasted to a logical
> port on the local hypervisor.
> </p>
>
> <p>
> - Table 34 matches and drops packets for which the logical input and
> + Table 39 matches and drops packets for which the logical input and
> output ports are the same and the MLF_ALLOW_LOOPBACK flag is not
> set. It also drops MLF_LOCAL_ONLY packets directed to a localnet
> port.
> It resubmits other packets to table 40.
> @@ -1545,7 +1545,7 @@
> <li>
> <p>
> Table 64 bypasses OpenFlow loopback when MLF_ALLOW_LOOPBACK is set.
> - Logical loopback was handled in table 34, but OpenFlow by default also
> + Logical loopback was handled in table 39, but OpenFlow by default also
> prevents loopback to the OpenFlow ingress port. Thus, when
> MLF_ALLOW_LOOPBACK is set, OpenFlow table 64 saves the OpenFlow
> ingress
> port, sets it to zero, resubmits to table 65 for logical-to-physical
> @@ -1583,8 +1583,8 @@
> traverse tables 0 to 65 as described in the previous section
> <code>Architectural Physical Life Cycle of a Packet</code>, using the
> logical datapath representing the logical switch that the sender is
> - attached to. At table 32, the packet will use the fallback flow that
> - resubmits locally to table 33 on the same hypervisor. In this case,
> + attached to. At table 37, the packet will use the fallback flow that
> + resubmits locally to table 38 on the same hypervisor. In this case,
> all of the processing from table 0 to table 65 occurs on the hypervisor
> where the sender resides.
> </p>
> @@ -1615,7 +1615,7 @@
> <p>
> The packet traverses tables 8 to 65 a third and final time. If the
> destination VM or container resides on a remote hypervisor, then table
> - 32 will send the packet on a tunnel port from the sender's hypervisor
> + 37 will send the packet on a tunnel port from the sender's hypervisor
> to the remote hypervisor. Finally table 65 will output the packet
> directly to the destination VM or container.
> </p>
> @@ -1642,9 +1642,9 @@
> When a hypervisor processes a packet on a logical datapath
> representing a logical switch, and the logical egress port is a
> <code>l3gateway</code> port representing connectivity to a gateway
> - router, the packet will match a flow in table 32 that sends the
> + router, the packet will match a flow in table 37 that sends the
> packet on a tunnel port to the chassis where the gateway router
> - resides. This processing in table 32 is done in the same manner as
> + resides. This processing in table 37 is done in the same manner as
> for VIFs.
> </p>
>
> @@ -1737,21 +1737,21 @@
> chassis, one additional mechanism is required. When a packet
> leaves the ingress pipeline and the logical egress port is the
> distributed gateway port, one of two different sets of actions is
> - required at table 32:
> + required at table 37:
> </p>
>
> <ul>
> <li>
> If the packet can be handled locally on the sender's hypervisor
> (e.g. one-to-one NAT traffic), then the packet should just be
> - resubmitted locally to table 33, in the normal manner for
> + resubmitted locally to table 38, in the normal manner for
> distributed logical patch ports.
> </li>
>
> <li>
> However, if the packet needs to be handled on the chassis
> associated with the distributed gateway port (e.g. one-to-many
> - SNAT traffic or non-NAT traffic), then table 32 must send the
> + SNAT traffic or non-NAT traffic), then table 37 must send the
> packet on a tunnel port to that chassis.
> </li>
> </ul>
> @@ -1763,11 +1763,11 @@
> egress port to the type <code>chassisredirect</code> logical port is
> simply a way to indicate that although the packet is destined for
> the distributed gateway port, it needs to be redirected to a
> - different chassis. At table 32, packets with this logical egress
> - port are sent to a specific chassis, in the same way that table 32
> + different chassis. At table 37, packets with this logical egress
> + port are sent to a specific chassis, in the same way that table 37
> directs packets whose logical egress port is a VIF or a type
> <code>l3gateway</code> port to different chassis. Once the packet
> - arrives at that chassis, table 33 resets the logical egress port to
> + arrives at that chassis, table 38 resets the logical egress port to
> the value representing the distributed gateway port. For each
> distributed gateway port, there is one type
> <code>chassisredirect</code> port, in addition to the distributed
> --
> 2.31.1
>
> _______________________________________________
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
