On Fri, Oct 24, 2014 at 2:57 PM, Thomas Graf <tg...@suug.ch> wrote: > 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. > This has never been issue in openvswitch. Plus we do not need loadable vport module to fix this issue.
> 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. > What is problem with current OVS built into kernel? > 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
