On Fri, Jan 10, 2025 at 5:24 PM Alexandra Rukomoinikova <[email protected]> wrote:
> Corrected OpenFlow table numbers in accordance > with real values. > > Signed-off-by: Alexandra Rukomoinikova <[email protected]> > --- > controller/physical.c | 26 ++++++------- > ovn-architecture.7.xml | 84 +++++++++++++++++++++--------------------- > 2 files changed, 55 insertions(+), 55 deletions(-) > > diff --git a/controller/physical.c b/controller/physical.c > index 16e312f9d..be26f7882 100644 > --- a/controller/physical.c > +++ b/controller/physical.c > @@ -925,12 +925,12 @@ put_local_common_flows(uint32_t dp_key, > > uint32_t port_key = pb->tunnel_key; > > - /* Table 40, priority 100. > + /* Table 43, priority 100. > * ======================= > * > * Implements output to local hypervisor. Each flow matches a > * logical output port on the local hypervisor, and resubmits to > - * table 41. > + * table 44. > */ > > ofpbuf_clear(ofpacts_p); > @@ -940,13 +940,13 @@ put_local_common_flows(uint32_t dp_key, > > put_zones_ofpacts(zone_ids, ofpacts_p); > > - /* Resubmit to table 41. */ > + /* Resubmit to table 44. */ > put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p); > ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100, > pb->header_.uuid.parts[0], &match, ofpacts_p, > &pb->header_.uuid); > > - /* Table 41, Priority 100. > + /* Table 44, Priority 100. > * ======================= > * > * Drop packets whose logical inport and outport are the same > @@ -1574,7 +1574,7 @@ 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 40, priority 100. > + /* Table 43, priority 100. > * ======================= > * > * Implements output to local hypervisor. Each flow matches a > @@ -1916,7 +1916,7 @@ consider_port_binding(struct ovsdb_idl_index > *sbrec_port_binding_by_name, > } > } > > - /* Table 39, priority 150. > + /* Table 42, priority 150. > * ======================= > * > * Handles packets received from ports of type "localport". These > @@ -1936,7 +1936,7 @@ consider_port_binding(struct ovsdb_idl_index > *sbrec_port_binding_by_name, > } > } else if (access_type == PORT_LOCALNET && !always_tunnel) { > /* Remote port connected by localnet port */ > - /* Table 40, priority 100. > + /* Table 43, priority 100. > * ======================= > * > * Implements switching to localnet port. Each flow matches a > @@ -1956,7 +1956,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 40. */ > + /* Resubmit to table 43. */ > put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p); > ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100, > binding->header_.uuid.parts[0], > @@ -1975,7 +1975,7 @@ consider_port_binding(struct ovsdb_idl_index > *sbrec_port_binding_by_name, > const char *redirect_type = smap_get(&binding->options, > "redirect-type"); > > - /* Table 40, priority 100. > + /* Table 43, priority 100. > * ======================= > * > * Handles traffic that needs to be sent to a remote hypervisor. Each > @@ -2658,7 +2658,7 @@ physical_run(struct physical_ctx *p_ctx, > */ > add_default_drop_flow(p_ctx, OFTABLE_PHY_TO_LOG, flow_table); > > - /* Table 37-38, priority 0. > + /* Table 40-43, priority 0. > * ======================== > * > * Default resubmit actions for OFTABLE_OUTPUT_LARGE_PKT_* tables. > @@ -2684,7 +2684,7 @@ physical_run(struct physical_ctx *p_ctx, > ofctrl_add_flow(flow_table, OFTABLE_OUTPUT_LARGE_PKT_PROCESS, 0, 0, > &match, > &ofpacts, hc_uuid); > > - /* Table 39, priority 150. > + /* Table 42, priority 150. > * ======================= > * > * Handles packets received from a VXLAN tunnel which get resubmitted > to > @@ -2703,7 +2703,7 @@ physical_run(struct physical_ctx *p_ctx, > ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0, > &match, &ofpacts, hc_uuid); > > - /* Table 39, priority 150. > + /* Table 42, priority 150. > * ======================= > * > * Packets that should not be sent to other hypervisors. > @@ -2717,7 +2717,7 @@ physical_run(struct physical_ctx *p_ctx, > ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, 0, > &match, &ofpacts, hc_uuid); > > - /* Table 39, Priority 0. > + /* Table 42, Priority 0. > * ======================= > * > * Resubmit packets that are not directed at tunnels or part of a > diff --git a/ovn-architecture.7.xml b/ovn-architecture.7.xml > index 640944faf..0672368f8 100644 > --- a/ovn-architecture.7.xml > +++ b/ovn-architecture.7.xml > @@ -1233,8 +1233,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 39, > - these packets are resubmitted to table 40 for local delivery by > + to determine the output port(s); when the packet reaches table 42, > + these packets are resubmitted to table 43 for local delivery by > checking a MLF_RCV_FROM_RAMP flag, which is set when the packet > arrives from a ramp tunnel. > </p> > @@ -1332,20 +1332,20 @@ > output port is known. These pieces of information are obtained > from the tunnel encapsulation metadata (see <code>Tunnel > Encapsulations</code> for encoding details). Then the actions > resubmit > - to table 38 to enter the logical egress pipeline. > + to table 45 to enter the logical egress pipeline. > </p> > </li> > > <li> > <p> > - OpenFlow tables 8 through 31 execute the logical ingress pipeline > from > + OpenFlow tables 8 through 39 execute the logical ingress pipeline > from > the <code>Logical_Flow</code> table in the OVN Southbound > database. > These tables are expressed entirely in terms of logical concepts > like > logical ports and logical datapaths. A big part of > <code>ovn-controller</code>'s job is to translate them into > equivalent > OpenFlow (in particular it translates the table numbers: > - <code>Logical_Flow</code> tables 0 through 23 become OpenFlow > tables 8 > - through 31). > + <code>Logical_Flow</code> tables 0 through 29 become OpenFlow > tables 8 > + through 39). > </p> > > <p> > @@ -1387,9 +1387,9 @@ > <dl> > <dt><code>output:</code></dt> > <dd> > - Implemented by resubmitting the packet to table 37. If the > pipeline > + Implemented by resubmitting the packet to table 40. If the > pipeline > executes more than one <code>output</code> action, then each > one is > - separately resubmitted to table 37. This can be used to send > + separately resubmitted to table 40. 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 > @@ -1453,13 +1453,13 @@ > > <li> > <p> > - OpenFlow tables 37 through 41 implement the <code>output</code> > action > - in the logical ingress pipeline. Specifically, table 37 serves > as an > - entry point to egress pipeline. Table 37 detects IP packets that > are > - too big for a corresponding interface. Table 38 produces ICMPv4 > + OpenFlow tables 40 through 44 implement the <code>output</code> > action > + in the logical ingress pipeline. Specifically, table 40 serves > as an > + entry point to egress pipeline. Table 40 detects IP packets that > are > + too big for a corresponding interface. Table 41 produces ICMPv4 > Fragmentation Needed (or ICMPv6 Too Big) errors and deliver them > back > - to the offending port. table 39 handles packets to remote > hypervisors, > - table 40 handles packets to the local hypervisor, and table 41 > checks > + to the offending port. table 42 handles packets to remote > hypervisors, > + table 43 handles packets to the local hypervisor, and table 44 > checks > whether packets whose logical ingress and egress port are the same > should be discarded. > </p> > @@ -1467,28 +1467,28 @@ > <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 40, for output to ports on the local hypervisor, > + Thus, flow table 43, 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 39. > + groups implement output to logical patch ports in table 42. > </p> > > <p> > - Each flow in table 39 matches on a logical output port for > unicast or > + Each flow in table 42 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 40.) For multicast > logical > + tunneled packet and pass it along to table 43.) 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 40. Table 39 > also > + hypervisor, then its actions also resubmit to table 43. Table 42 > also > includes: > </p> > > @@ -1496,7 +1496,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 40 for local delivery. Packets received from ramp > switch > + to table 43 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. > @@ -1504,7 +1504,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 40 for local delivery. Ports of type > + these packets to table 43 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> > @@ -1519,41 +1519,41 @@ > packets, the packets only need to be delivered to local ports. > </li> > <li> > - A fallback flow that resubmits to table 40 if there is no other > + A fallback flow that resubmits to table 43 if there is no other > match. > </li> > </ul> > > <p> > - Flows in table 40 resemble those in table 39 but for logical > ports that > + Flows in table 43 resemble those in table 42 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 41. > For > + on the local hypervisor, the actions just resubmit to table 44. > 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 > - 41. > + 44. > </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 39 to reach the remote > port, a > - flow is added in table 40 to switch the logical outport to the > localnet > - port, and resubmit to table 40 as if it were unicasted to a > logical > + case, instead of adding a flow in table 42 to reach the remote > port, a > + flow is added in table 43 to switch the logical outport to the > localnet > + port, and resubmit to table 43 as if it were unicasted to a > logical > port on the local hypervisor. > </p> > > <p> > - Table 41 matches and drops packets for which the logical input and > + Table 44 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 42. > + It resubmits other packets to table 45. > </p> > </li> > > <li> > <p> > - OpenFlow tables 42 through 62 execute the logical egress pipeline > from > + OpenFlow tables 45 through 62 execute the logical egress pipeline > from > the <code>Logical_Flow</code> table in the OVN Southbound > database. > The egress pipeline can perform a final stage of validation before > packet delivery. Eventually, it may execute an > <code>output</code> > @@ -1572,7 +1572,7 @@ > <li> > <p> > Table 64 bypasses OpenFlow loopback when MLF_ALLOW_LOOPBACK is set. > - Logical loopback was handled in table 41, but OpenFlow by default > also > + Logical loopback was handled in table 44, 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 > @@ -1610,8 +1610,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 39, the packet will use the fallback flow that > - resubmits locally to table 40 on the same hypervisor. In this case, > + attached to. At table 42, the packet will use the fallback flow that > + resubmits locally to table 43 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> > @@ -1669,9 +1669,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 39 that sends the > + router, the packet will match a flow in table 42 that sends the > packet on a tunnel port to the chassis where the gateway router > - resides. This processing in table 39 is done in the same manner as > + resides. This processing in table 42 is done in the same manner as > for VIFs. > </p> > > @@ -1764,21 +1764,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 39: > + required at table 42: > </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 40, in the normal manner for > + resubmitted locally to table 43, 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 39 must send the > + SNAT traffic or non-NAT traffic), then table 42 must send the > packet on a tunnel port to that chassis. > </li> > </ul> > @@ -1790,11 +1790,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 39, packets with this logical egress > - port are sent to a specific chassis, in the same way that table 39 > + different chassis. At table 42, packets with this logical egress > + port are sent to a specific chassis, in the same way that table 42 > 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 40 resets the logical egress port to > + arrives at that chassis, table 43 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.34.1 > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > Looks good to me, thanks. We probably need to find a better way to propagate those numbers dynamically. Acked-by: Ales Musil <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
