On Tue, Aug 30, 2016 at 1:17 PM, Ben Pfaff <b...@ovn.org> wrote: > 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?
I originally thought that passing an ofproto was perhaps a little more generic and nicer but you're right that this is probably not worth the layering issues. It's also cleaner to avoid using an ofproto now that I've rebased this patch on top of my earlier ovs-ofctl changes. Since those patches made ovs-ofctl need to generate a tunnel metadata table, with the original version of the patch it would also be necessary to have a fake ofproto to contain it. If we only pass around the tun_table, then this isn't needed. I'll send a rebased version that switches to passing around a struct tun_table shortly. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
