> -----Original Message----- > From: Gray, Mark D [mailto:mark.d.g...@intel.com] > Sent: Thursday, June 11, 2015 11:02 AM > To: Zayats, Michael; dev@openvswitch.org > Subject: RE: [ovs-dev] [PATCH] vswitchd: adding plugin infrastructre > > > > > Per this patch ovs-vswitchd searches for shared objects, with a > > certain set of exposed routines, in a specific configurable path. > > Once found, all compatible plugins are loaded and their routines are > > called at appropriate points of the daemon execution. > > > > Personally, I like this functionality. I didn’t do a full review as I > wanted to see what others thought of it. > > What is your use case for this? Do you want to distribute a netdev as a > binary blob?
The main use case is for developers who create providers for their respective hardware, to keep them in separate repos and not having to contaminate the main code of OVS with ifdefs at makefiles and C levels. Especially if they can't upstream their code, then they end up with maintaining their own patch, effectively forking OVS. People will probably figure out many other use cases where they would add custom, non-generic and thus non "upstreamable" functionality to ovs-vswitchd without forking it. > > Is there any reason you left out the dpif? No reason, just missed it. Can add the hook for dpif provider registration. > > Previously, we maintained a separate dpif-provider and I often wanted us > to just provide the dpif code in our repo and plug it into the upper > layers of ovs. > However even if we did this, one of the problems that we would have > faced was that the dpif interface changed quite regularly and was > difficult to maintain (it was a nightmare when megaflows were > introduced!). So in our case, I kind of felt to get the real value out > of this we would need some kind of stability in the ABI/API of the dpif > interface. From ABI perspective - the plugin should be built for the specific OVS. Similar to out of tree kernel modules. For API stability, that's a more generic matter adding burden to the providers developers regardless of being pluginized or not... Hopefully it gets more stable. > > As a general comment, why didn’t you pluginize (if that is a word) the > current set of netdevs and ofprotos in this patch? It might be a logical next step, once we agree on the infra and get it added. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
