hi Daniele. Sorry I missed this message but Ciara just pointed this out to me.
From: Daniele Di Proietto [mailto:diproiet...@ovn.org] Sent: Monday, August 15, 2016 6:10 PM To: Mooney, Sean K <sean.k.moo...@intel.com> Cc: Loftus, Ciara <ciara.lof...@intel.com>; dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v4 3/3] netdev-dpdk: vHost client mode and reconnect Hi Sean, 2016-08-15 9:04 GMT-07:00 Mooney, Sean K <sean.k.moo...@intel.com<mailto:sean.k.moo...@intel.com>>: Hi Daniele Sorry to top post but I have just read back over the last couple of revisions of this patch. No problem, thanks for stepping in. As I said many times during the review of this series I'm not sure what the best interface would be, and I really appreciate any feedback on this. I noticed that you requested that the vhost-driver-mode flag be removed From the Open_vSwitch table. The vhost-driver-mode flag was included in The original patch for two reasons 1 to configure the global driver mode In my opinion Open vSwitch is not the right place to store this global configuration parameter. I think we should put it as high in the stack as possible. Isn't there another place to store it in OpenStack? [Mooney, Sean K] OpenStack make the choice instead of requiring ovs to store this information as a global parameter as long as we can detect if the feature is available. And 2 to provide a way to detect if reconnect/qemu server mode was available. I see your point, we need feature detection for this. Perhaps we can use another type for client ports, like "dpdkvhostuserclient". I think it make senses to have a separate class, since the interface is different anyway. It would be easy then to detect the feature based on the available iface_types. [Mooney, Sean K] Yes if we keep the current dpdkvhostuser port type for qemu:clinet dpdk:server mode and introduced a "dpdkvhostuserclient" for qemu the new qemu:server dpdk:clinet mode of vhost-user that would work perfectly for my usecase. it would be a trivial change in openstack and this should work equally well in odl and ovn. Could this be included in the 2.6 release? What do you think? Thanks, Daniele Without the global flag or a similar mechanism to expose the capability via The ovsdb I cannot complete the OpenStack integrations. https://review.openstack.org/#/c/344997/ I have one proposal which is to store the feature list currently in the faq https://github.com/openvswitch/ovs/blob/master/FAQ.md#q-are-all-features-available-with-all-datapaths in the ovsdb. This can be retrieve remotely via the ovs db by openstack or any other orchestrator to make dession based on the feature detected. If you have another suggestion I would be glad to adapt my OpenStack change To use another mechanism to detect the support for reconnect but without the vhost-driver-mode flag I am currently blocked. I will make as a separate thread not to discuss feature discovery in general Not to distract from this review Regards Sean. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
