> Hi Sean, > > 2016-08-15 9:04 GMT-07:00 Mooney, Sean K <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.
I submitted a patch that implements the suggested 'dpdkvhostuserclient' port type. http://openvswitch.org/pipermail/dev/2016-August/078199.html I think it's a good idea and a cleaner approach. Please add your 'Suggested-by' Daniele if you decide to apply the patch, I forgot it in the v1 - apologies. Will include it next time if there is another revision. Thanks, Ciara > 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
