I have mixed feelings about this patch. On one hand, this has largely
future-proofed the document since we won't need to update table
numbers any more. But on the other hand, I don't know how useful the
constant names are for readers of the manpage. Someone installing from
a package manager may not have the accompanying source files to
translate from the constants to the table numbers they see when
inspecting OpenFlow.

I think for the task of documentation cleanup, the table numbers
should just be updated to be accurate.

A future project could change ovn-sb.xml to use the constants, then
the XML could be fed into an ovn-debug-like program to replace the
constant values with their correct table values at compile time. But
that's outside the scope of these changes.



On Fri, Aug 21, 2026 at 3:58 PM Jacob Tanenbaum via dev
<[email protected]> wrote:
>
> commit 9c4ab63fb updated the table numbers but did not update the
> documentation the referenced the table numbers.
>
> Fixes: 9c4ab635b526 ("controller: Add room between OpenFlow table stages.")
> Assisted-by: Claude Opus 4.6, Claude Code
> Signed-off-by: Jacob Tanenbaum <[email protected]>
>
> ---
> v3 - corrected the "Fixes" tag
> ---
>  ovn-sb.xml | 41 ++++++++++++++++++++++-------------------
>  1 file changed, 22 insertions(+), 19 deletions(-)
>
> diff --git a/ovn-sb.xml b/ovn-sb.xml
> index a18fef45b..013d498e3 100644
> --- a/ovn-sb.xml
> +++ b/ovn-sb.xml
> @@ -2763,22 +2763,24 @@ tcp.flags = RST;
>
>            <p>
>              This action translates to an openflow "learn" action that inserts
> -            two new flows in tables 76 and 77.
> +            two new flows in tables referenced by
> +            <code>OFTABLE_ECMP_NH_MAC</code> and 
> <code>OFTABLE_ECMP_NH</code>.
>            </p>
>
>            <ul>
>              <li>
>                Match on the 5-tuple and the expected next-hop mac address
> -              in table 76: <code>nw_src=ip0</code>, <code>nw_dst=ip1</code>,
> +              in table <code>OFTABLE_ECMP_NH_MAC</code>:
> +              <code>nw_src=ip0</code>, <code>nw_dst=ip1</code>,
>                <code>ip_proto</code>,<code>tp_src=l4_port0</code>,
>                <code>tp_dst=l4_port1</code>,<code>dl_src=ethaddr</code> and
>                set <code>reg9[5]</code>.
>              </li>
>              <li>
> -              Match on the 5-tuple in table 77: <code>nw_src=ip1</code>,
> -              <code>nw_dst=ip0</code>, <code>ip_proto</code>,
> -              <code>tp_src=l4_port1</code>, <code>tp_dst=l4_port0</code>
> -              and set <code>reg9[5]</code> to 1
> +              Match on the 5-tuple in table <code>OFTABLE_ECMP_NH</code>:
> +              <code>nw_src=ip1</code>, <code>nw_dst=ip0</code>,
> +              <code>ip_proto</code>, <code>tp_src=l4_port1</code>,
> +              <code>tp_dst=l4_port0</code> and set <code>reg9[5]</code> to 1
>              </li>
>            </ul>
>
> @@ -2792,8 +2794,8 @@ tcp.flags = RST;
>          <dd>
>            <p>
>              This action checks if the packet under consideration matches
> -            any flow in table 76. If it is so, then the 1-bit destination
> -            register <var>R</var> is set to 1.
> +            any flow in table <code>OFTABLE_ECMP_NH_MAC</code>. If it is so,
> +            then the 1-bit destination register <var>R</var> is set to 1.
>            </p>
>          </dd>
>
> @@ -2801,8 +2803,8 @@ tcp.flags = RST;
>          <dd>
>            <p>
>              This action checks if the packet under consideration matches
> -            any flow in table 77. If it is so, then the 1-bit destination
> -            register <var>R</var> is set to 1.
> +            any flow in table <code>OFTABLE_ECMP_NH</code>. If it is so, then
> +            the 1-bit destination register <var>R</var> is set to 1.
>            </p>
>          </dd>
>
> @@ -2821,17 +2823,18 @@ tcp.flags = RST;
>
>            <p>
>              This action translates to an openflow "learn" action that inserts
> -            a new flow in table 78.
> +            a new flow in table <code>OFTABLE_CHK_LB_AFFINITY</code>.
>            </p>
>
>            <ul>
>              <li>
> -              Match on the 4-tuple in table 78: <code>nw_src=ip 
> client</code>,
> -              <code>nw_dst=vip ip</code>, <code>ip_proto</code>,
> -              <code>tp_dst=vip port</code> and set <code>reg9[6]</code> to 1,
> -              <code>reg4</code> and <code>reg8</code> to backend ip and port
> -              respectively. For IPv6 register <code>xxreg1</code> is used to
> -              store the backend ip.
> +              Match on the 4-tuple in table
> +              <code>OFTABLE_CHK_LB_AFFINITY</code>:
> +              <code>nw_src=ip client</code>, <code>nw_dst=vip ip</code>,
> +              <code>ip_proto</code>, <code>tp_dst=vip port</code> and set
> +              <code>reg9[6]</code> to 1, <code>reg4</code> and
> +              <code>reg8</code> to backend ip and port respectively. For IPv6
> +              register <code>xxreg1</code> is used to store the backend ip.
>              </li>
>            </ul>
>
> @@ -2845,8 +2848,8 @@ tcp.flags = RST;
>          <dd>
>            <p>
>              This action checks if the packet under consideration matches any
> -            flow in table 78. If it is so, then the 1-bit destination
> -            register <var>R</var> is set to 1.
> +            flow in table <code>OFTABLE_CHK_LB_AFFINITY</code>. If it is so,
> +            then the 1-bit destination register <var>R</var> is set to 1.
>            </p>
>          </dd>
>
> --
> 2.55.0
>
> _______________________________________________
> dev mailing list
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to