[ovs-dev] [PATCH v2 rebase] tun-metadata: Manage tunnel TLV mapping table on a per-bridge basis.

[Ben Pfaff]

On Thu, Sep 15, 2016 at 09:28:37AM -0700, Jesse Gross wrote:
> When using tunnel TLVs (at the moment, this means Geneve options), a
> controller must first map the class and type onto an appropriate OXM
> field so that it can be used in OVS flow operations. This table is
> managed using OpenFlow extensions.
> 
> The original code that added support for TLVs made the mapping table
> global as a simplification. However, this is not really logically
> correct as the OpenFlow management commands are operating on a per-bridge
> basis. This removes the original limitation to make the table per-bridge.
> 
> One nice result of this change is that it is generally clearer whether
> the tunnel metadata is in datapath or OpenFlow format. Rather than
> allowing ad-hoc format changes and trying to handle both formats in the
> tunnel metadata functions, the format is more clearly separated by function.
> Datapaths (both kernel and userspace) use datapath format and it is not
> changed during the upcall process. At the beginning of action translation,
> tunnel metadata is converted to OpenFlow format and flows and wildcards
> are translated back at the end of the process.
> 
> As an additional benefit, this change improves performance in some flow
> setup situations by keeping the tunnel metadata in the original packet
> format in more cases. This helps when copies need to be made as the amount
> of data touched is only what is present in the packet rather than the
> maximum amount of metadata supported.
> 
> Co-authored-by: Madhu Challa <challa at noironetworks.com>
> Signed-off-by: Madhu Challa <challa at noironetworks.com>
> Signed-off-by: Jesse Gross <jesse at kernel.org>
> ---
> This is a rebased version of the previously posted patch which no longer
> applies cleanly.
> 
> v2: Pass 'struct tun_table' instead of 'struct ofproto' for functions that
>     need to access tunnel metadata.

Thanks a lot Jesse.  I like this much better and, surprisingly, it
yields a net reduction in code.

I think that this should update NEWS to reflect the new feature.

This appears to cause a new test failure:
    2235: ovn -- 3 HVs, 1 VIFs/HV, 1 software GW, 1 LS    FAILED (ovn.at:1942)

I couldn't immediately figure out why.  With the patch this test seems
to fail consistently (10 failures out of 10) and without it it succeeds
(0 failures out of 10).

If you can figure something out there,
Acked-by: Ben Pfaff <blp at ovn.org>

Thanks again!