On 10/24/14 at 10:47am, Pravin Shelar wrote: > On Wed, Oct 22, 2014 at 8:29 AM, Thomas Graf <tg...@suug.ch> wrote: > > The internal and netdev vport remain part of openvswitch.ko. Encap > > vports including vxlan, gre, and geneve can be built as separate > > modules and are loaded on demand. Modules can be unloaded after use. > > Datapath ports keep a reference to the vport module during their > > lifetime. > > > > Allows to remove the error prone maintenance of the global list > > vport_ops_list. > > > How error prone is this interface, can you give example? Set of ovs > vport type is been pretty stable, so am not sure if we need loadable > module support for vports implementations.
I was refering to how many other kernel APIs have been designed, a registration API allowing a vport to be implemented exclusively in the scope of a single file tends to be cleaner than having to touch multiple files and maintaining an init list. It also allows for OVS to be built into vmlinuz while vports can remain as modules even if vxlan itself is built as a module. As for new vports, GUE and LIS are candidates, encrypted VXLAN might look for support and there are several VXLAN extensions currently proposed as IETF drafts which might require new vports. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
