On Tue, Aug 23, 2016 at 02:28:27PM -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 <cha...@noironetworks.com> > Signed-off-by: Madhu Challa <cha...@noironetworks.com> > Signed-off-by: Jesse Gross <je...@kernel.org>
It's not really great to have the library layer looking into the ofproto layer. Is there a way to avoid that? Perhaps callers should pass in a tun_table instead of an ofproto? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
