)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c3f8de526d6a6b000811655ce406aac2aa84a329","unresolved":false,"context_lines":[{"line_number":9,"context_line":"Propose to extend LibvirtGenericVIFDriver class to support"},{"line_number":10,"context_line":"dpdkvhost. This will allow Openvswitch derivatives that"},{"line_number":11,"context_line":"use Intel(R) DPDK to be used with Openstack."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: Ibcf7d5354e39fa3ad4d021acff8d3e3e50c0900d"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"baada198_3efd3409","line":12,"updated":"2014-07-23 18:45:07.000000000","message":"BP reference missing","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8dce3bee85e5c0a05a617ad153a892201e5d7c76","unresolved":false,"context_lines":[{"line_number":9,"context_line":"Propose to extend LibvirtGenericVIFDriver class to support"},{"line_number":10,"context_line":"dpdkvhost. This will allow Openvswitch derivatives that"},{"line_number":11,"context_line":"use Intel(R) DPDK to be used with Openstack."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: Ibcf7d5354e39fa3ad4d021acff8d3e3e50c0900d"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"baada198_b85ce0f1","line":12,"in_reply_to":"baada198_3efd3409","updated":"2014-07-24 11:40:31.000000000","message":"hi i will add this  in the next commit \ni will also update the title to something more appropriate.","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"}],"specs/juno/libvirt-ovs-use-usvhost.rst":[{"author":{"_account_id":7916,"name":"Luke Gorrie","email":"luke@snabb.co","username":"lukego"},"change_message_id":"ab600738cb7561fee2e1c05dc64528086c17eae7","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Problem description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Existing libvirt ovs vif bindings don\u0027t support userspace vhost on"},{"line_number":17,"context_line":"Intel(R) DPDK enabled virtual switches (ie. Openvswitch ,"},{"line_number":18,"context_line":"Intel DPDK Accelerated vSwitch)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_42a00bf4","line":16,"updated":"2014-06-19 09:40:33.000000000","message":"Referring to Section 22 of the PDF you reference below (DPDK \"Vhost Sample Application\"):\n\nDo I understand correctly that this is not based on the new QEMU vhost-user feature but rather on DPDK code that uses FUSE to intercept access to /dev/vhost-net and divert ioctl()s into the vswitch process instead of the kernel? (i.e. an out-of-QEMU-tree equivalent of vhost-user based on FUSE?)\n\nHave you considered porting to vhost-user, now that this is available? In that case we could perhaps join forces and make the VIF_VHOSTUSER work for DPDK-based vswitches too? Or is there something that makes the DPDK implementation different/superior?","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"18aa641d548ad7a87a1963690548f0f981e8f5df","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Problem description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Existing libvirt ovs vif bindings don\u0027t support userspace vhost on"},{"line_number":17,"context_line":"Intel(R) DPDK enabled virtual switches (ie. Openvswitch ,"},{"line_number":18,"context_line":"Intel DPDK Accelerated vSwitch)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_c4050611","line":16,"in_reply_to":"1ae5cdf2_42a00bf4","updated":"2014-06-19 10:58:23.000000000","message":"Yes, you\u0027re correct this does not use the vhost-user in qemu.\nWe plan to use vhost-user once it becomes available (last time i checked were not included in both qemu or libvirt)\nThe vswitches we want to enable are ovs compatible (one is in fact ovs with userpace dpdk datapath) so we want to benefit from the existing ovs dirvers in neutron ml2 (mech_openvsiwtch, mech_odl).\nI think we will try to modify ovs vif bindings to use VIF_VHOSTUSER when it\u0027s needed. It\u0027s  unclear how to do it in a way to make both nova and neutron core devs happy.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":7916,"name":"Luke Gorrie","email":"luke@snabb.co","username":"lukego"},"change_message_id":"f2442f8665a06363a971c790d1215e655be85727","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Problem description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Existing libvirt ovs vif bindings don\u0027t support userspace vhost on"},{"line_number":17,"context_line":"Intel(R) DPDK enabled virtual switches (ie. Openvswitch ,"},{"line_number":18,"context_line":"Intel DPDK Accelerated vSwitch)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_969a4c12","line":16,"in_reply_to":"1ae5cdf2_6a8cf9d7","updated":"2014-06-19 14:16:17.000000000","message":"Snabb design is simple: Neutron writes the whole configuration (ports, networks, security groups, QoS, etc) into a config file, then Snabb Switch loads that config file and processes the traffic accordingly.\n\nCurrently we implement the Neutron config using a mix of software and hardware. For example, the actual packet switching is done in hardware using the VMDq feature of the NIC. Security Groups are currently done in software but we are working on offloading a subset onto the Flow Director hardware feature.\n\nThere is no OpenFlow etc in this design.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"0134facadbdf4b26604cb5668a7764ceb352d584","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Problem description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Existing libvirt ovs vif bindings don\u0027t support userspace vhost on"},{"line_number":17,"context_line":"Intel(R) DPDK enabled virtual switches (ie. Openvswitch ,"},{"line_number":18,"context_line":"Intel DPDK Accelerated vSwitch)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_6a8cf9d7","line":16,"in_reply_to":"1ae5cdf2_87e9401c","updated":"2014-06-19 12:13:25.000000000","message":"Yes iptables can\u0027t be used with userspace switches. There is openflow sg driver in the works https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver\nthis will help close the gap. How are security groups supported with the snabb switch?","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":7916,"name":"Luke Gorrie","email":"luke@snabb.co","username":"lukego"},"change_message_id":"5106363ad079013def995016b62ebee935866e23","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Problem description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Existing libvirt ovs vif bindings don\u0027t support userspace vhost on"},{"line_number":17,"context_line":"Intel(R) DPDK enabled virtual switches (ie. Openvswitch ,"},{"line_number":18,"context_line":"Intel DPDK Accelerated vSwitch)."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_87e9401c","line":16,"in_reply_to":"1ae5cdf2_c4050611","updated":"2014-06-19 11:33:43.000000000","message":"More background questions to understand the solution :-)\n\nMy understanding is that the existing OVS plugin also uses Linux kernel networking features such as iptables and ebtables in addition to OVS itself. Is that correct? Will this still be possible when you move the OVS dataplane out of the kernel and into userspace? If not, how will the iptables/ebtables functionality be implemented?","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c014a8b56e5549a9e211152a8ddc709d795dce89","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Those methods would be called from {get_config, plug,unplug}_ovs  depending"},{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_0bea170f","line":27,"updated":"2014-05-31 07:17:22.000000000","message":"Perhaps it would be more appropriate to use a binding_type from Neutron than a config item?  Given that, presumably, Neutron will have a different combination of settings if it\u0027s controlling a userspace switch, it seems silly to insist on changing both the Neutron config and, in lockstep, the Nova config (which is what the binding_type was created to avoid).","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"8a5fee0dbbf0b26ac384135c0314ebfd85fb24bb","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Those methods would be called from {get_config, plug,unplug}_ovs  depending"},{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_2805fd79","line":27,"in_reply_to":"1ae5cdf2_0bea170f","updated":"2014-06-02 09:33:08.000000000","message":"This approach allows to use existing mech_openvswitch and mech_odl from Neutron ML2 plugin with userspace vwitches. In the end we want to have runtime detection of ovs switch type, the config option would be removed then.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"592948c613c62ca0c7d279fb29ac9b4084985fbe","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Those methods would be called from {get_config, plug,unplug}_ovs  depending"},{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_67414709","line":27,"in_reply_to":"1ae5cdf2_2805fd79","updated":"2014-06-23 03:28:19.000000000","message":"I don\u0027t think a config option helps with automatic detection of binding types any more than binding_type passing does.  Can you perhaps explain a bit more why this works?\n\n(One model I discussed with garyk a long long while ago is that this should be a negotiation - Nova (presumably by checking with the hypervisor driver, and, in the case of libvirt, likely running a few queries of the underlying code) tells Neutron what binding types it supports, and Neutron picks the best one it can work with or declines to bind if it simply can\u0027t attach.  Is that any good to you?)","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"ba73148a779d7126f7ec1c434eeeb9501fced249","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Those methods would be called from {get_config, plug,unplug}_ovs  depending"},{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_9d6f0d60","line":27,"in_reply_to":"1ae5cdf2_67414709","updated":"2014-06-25 17:07:19.000000000","message":"Config option doesn\u0027t help with automatic detection. The detection mechanism is an alternative to the config option. The binding_type passed by neutron is not enough to tell which kind of ovs is running on the compute node.\n\nHaving the hypervisor provide a list of available bindings fixes the problem a little (i.e. there would be a clear place where to put vswitch config/detection). But then libvirt would have to know all the vswitches out there and the types of bindings they support.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c1de9f6444183ee963b19c4b40adee43e10787b9","unresolved":false,"context_lines":[{"line_number":24,"context_line":"Those methods would be called from {get_config, plug,unplug}_ovs  depending"},{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_e4f4ccd0","line":27,"in_reply_to":"1ae5cdf2_9d6f0d60","updated":"2014-06-26 19:11:14.000000000","message":"Actually, the binding type is enough - in the sense that the binding type should specify precisely how Nova attaches to the port Neutron is offering it.  And libvirt does not have to know about every switch out there, but yes, it absolutely does have to know about the types of bindings they support - that is unavoidable - because you have to configure the VM to attach in a certain way based on the binding type - and precisely the point of having a binding_type in the first place, so that Neutron and only Neutron needs to know how what binding is required and Nova and only Nova needs to know how to make that work for the hypervisor in question (which is not exclusively libvirt, incidentally).","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"71f1ebf152a76ebc9dd9e0195bc6ab900a3d83dd","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_1d6a01ed","line":28,"updated":"2014-06-18 17:21:44.000000000","message":"We did alot of work in previous cycles to explicitly get away from having global flags in nova.conf that affect all networking setup, so that we can support multiple different networking setups per compute host, with all the information coming from Neutron.  Adding in new nova config options which cause us to ignore/override the Neutron provided config is a major step backwards that just isn\u0027t going to fly.\n\nIn addition there is already a spec that\u0027s been created to support vhost-user functionality that is designed following the preferred config approach.\n\nhttps://review.openstack.org/#/c/96140/","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"c2a53b13c8d6e05fe37e10d651cf4f29e6fcb645","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_92839703","line":28,"in_reply_to":"1ae5cdf2_0706c3cd","updated":"2014-07-02 14:38:08.000000000","message":"I agree with Ian\u0027s point earlier that Nova should inform Neutron of what VIF types it is capable of using, so then when there is a possible choice of many VIFs for a network, Neutron can choose the best one to use with Nova. This handles the upgrade case better, where we have a mix of new \u0026 old Nova nodes, but want to turn on the new vhost for new nova nodes only.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90294991de24d94ead8fe151f48a85daaa4bcbec","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_a6e87ab5","line":28,"in_reply_to":"1ae5cdf2_147c6fb5","updated":"2014-07-02 01:05:42.000000000","message":"Daniel,ijw: \nin havana  Big switch networks introduced a mechanism\nin their neutron plunging to allow the vif type \nto be set per host_id \n\nsee https://blueprints.launchpad.net/neutron/+spec/hostid-vif-override\n\nextrapolating form there approach two changes would be required to pass the information form neutron to nova.\n\nthe follow could be added to the ml2.ini\n\nnode_override_vif_\u003cvif_type\u003e\u003d\u003chost-id\u003e,\u003chost-id\u003e,...\nnode_overrride_vif_VHOSTUSER\u003dhost-id1,host-id2\n\nand\n\n_extend_port_dict_binding  would be overridden as is done in \nneutron/plugins/bigswitch/plugin.py with an addtional check below\n\n        if hostid:\n            port[portbindings.HOST_ID] \u003d hostid\n            override \u003d self._check_hostvif_override(hostid)\n            if override:\n                cfg_vif_type \u003d override\n\nnova would then simply check the vif-type to determine \nif the vhostuser or standard ovs vif binding should be used.\n\nthis modification would be made in mech_openvswitch and mech_odl\n\nWould this be an acceptable solution.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"38b4a5e1fa542341499057073c10606c65441a60","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_4384ac0a","line":28,"in_reply_to":"1ae5cdf2_1d6a01ed","updated":"2014-06-18 18:02:36.000000000","message":"I undestand that. The problem with the spec you mention is that it relies on having an ML2 driver in neutron. As the vswitches we want to support are both ovs compatible we would like to leverage existing mech_openvsiwtch and mech_odl. Would it help if we would get rid of the config switch and add some detection mechanism to check if ovs runnig on the node requires userspace vhost?","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"592948c613c62ca0c7d279fb29ac9b4084985fbe","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_0706c3cd","line":28,"in_reply_to":"1ae5cdf2_42e2cbd5","updated":"2014-06-23 03:28:19.000000000","message":"I do think it would be useful for hypervisors to describe their plugging types to Neutron, per above, since it\u0027s still theoretically possible for Neutron to choose a binding type the hypervisor doesn\u0027t support (imagine if this was a Xen hypervisor, and also consider the currently rather awkward cases where you have a mixed hypervisor system with different plugging types) so arguably there is a check you could do in Nova.  I don\u0027t think there should be any config required in Nova for this, though.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"7e776304bd785f60cc6ddc98de83b4d4f92e9a59","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_42e2cbd5","line":28,"in_reply_to":"1ae5cdf2_4384ac0a","updated":"2014-06-19 09:49:11.000000000","message":"Nova shouldn\u0027t do such a check IMHO. Neutron should have any knowledge of the vswitches it is working work \u0026 if it is appropriate to use vhost user it should be able to tell Nova that.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"592948c613c62ca0c7d279fb29ac9b4084985fbe","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_675867f9","line":28,"in_reply_to":"1ae5cdf2_4384ac0a","updated":"2014-06-23 03:28:19.000000000","message":"The specific patch Daniel\u0027s pointing to is in Nova, and as far as I can see doesn\u0027t have any dependency at all on how Neutron is configured.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"b8811e63d1f1560829711ffbf5e49e437ed49961","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_147c6fb5","line":28,"in_reply_to":"1ae5cdf2_64befcd5","updated":"2014-06-27 10:48:04.000000000","message":"Thanks, for feedback. We will try to solve the problem on Neutron side. \n\nWould it be enough if we would keep binding_type the same (VIF_TYPE_OVS) but additional information would be passed from neutron in binding:profile ?","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"ba73148a779d7126f7ec1c434eeeb9501fced249","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_d80603cd","line":28,"in_reply_to":"1ae5cdf2_675867f9","updated":"2014-06-25 17:07:19.000000000","message":"I\u0027ll reiterate the spec and the code to use VIF_TYPE_VHOSTUSER. But we will still need to modify VIF_TYPE_OVS code to use VIF_TYPE_VHOSTUSER bindings when dpdk enabled ovs is running on the node. Neutron doesn\u0027t distinguish between normal ovs and dpkd enabled ovs.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c1de9f6444183ee963b19c4b40adee43e10787b9","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_64befcd5","line":28,"in_reply_to":"1ae5cdf2_d80603cd","updated":"2014-06-26 19:11:14.000000000","message":"Now there, I think you need a setting in Neutron to make it clear that it\u0027s managing either a userspace or a kernelspace OVS - but that\u0027s fine.  Neutron should know these things, Nova shouldn\u0027t.\n\nI presume this is an either-or, as in, there\u0027s no case where you would want to run both the userspace and the kernelspace NIC (and note, Nova doesn\u0027t preclude this, another reason why you don\u0027t want an either-or setting in Nova).","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66cd140b56b26b3ced44bf2e95ebd94244b98fd1","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_9f8a70bd","line":28,"in_reply_to":"baada198_6656055e","updated":"2014-07-04 09:36:31.000000000","message":"hi ijw i think by modifying the mechanism used in the bigswitch plugin we can address both points.\n\nthe bigswitch mechanisium allows neutron to select which of the VIF_TYPE to use.  to this point i will refactor our nova code to add a VIF_DPDKVHOST to the LibvirtGenericVIFDriver.\n\nnova would then just select the binding based on the the VIF_TYPE set by neutron.\n\nto address daniel\u0027s concern i propose the following.\nto chose the vif_type in neuton. the _extend_port_dict_binding function in the openvswitch and opendaylight ml2 mechanism driver will be override with an additional check.\n\n if hostid:\nport[portbindings.HOST_ID] \u003d hostid\noverride \u003d self._check_hostvif_override(hostid)\nif override:\nvif_type \u003d override\n\nhowever unlike the Bigswitch plugin the operation of self._check_hostvif_override(hostid) will be changed.\n\nfor the openvswitch mechanism driver a new function will be added to the openvswitch agent get_dpdkvhost_enabled.\nif get_dpdkvhost_enabled return true VIF_DPDKVHOST will be used otherwise the current ovs vif type will be used.\n\nget_dpdkvhost_enabled will preform the following checks\nfirst it i wll check the datapath_type of br-int on the node via ovs_lib.\n\nif the datapath_type\u003ddpdk intels dpdk openvswitch is been used and it will return true.\n\nif the datapath_type\u003dnetdev it will then check the command dline ovs-vswitchd was run with. if the command line contains --dpdk it will return true. \n\nin all other cases get_dpdkvhost_enabled will return false.\n\nfor the opendaylight mechanism driver there is no agent on the compute node so get_dpdkvhost_enabled will be implement by the opendaylight plugin with the same logic.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c6430609b02da31273aedd0a1c0117e48041ea63","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_750cdb3b","line":28,"in_reply_to":"baada198_9f8a70bd","updated":"2014-07-04 10:22:55.000000000","message":"if the approach above is acceptable i will split this out into two specs. the first, this one will be updated  to reflect the nova changes only but will  have a dependency on the second spec which i will create in the neutron project. \n\nthe second spec will detail the auto detect mechanism above and the changes to the  openvswitch and opendaylight ml2 mechanism driver. i will also reference the nova spec in the neutron spec.\n\ni will also call out that this change is to support qemu version \u003c 2.0 and that in the k/L timeframe when support for qemu\u0027s 2.1 vhost-user mechanism is added to both openvswitches that this will be the preferred way to connect to the switch if qemu2.1+ is used.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"476f44d1dbf1647809f05d3b1a818ccbde7f86b1","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_e9ff6c65","line":28,"in_reply_to":"baada198_a6e87ab5","updated":"2014-07-03 08:52:54.000000000","message":"I don\u0027t really think the hostid-vif-override design is very good. It places a significant burden on the admin to have to setup potentially huge numbers of host id mappings. It just doesn\u0027t seem like it is a scalable approach.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"8e5602bf137d77110ebfbb29ce3965dcfaa54493","unresolved":false,"context_lines":[{"line_number":25,"context_line":"on the value of ovs_use_usvhost config parameter."},{"line_number":26,"context_line":"The {get_config, plug,unplug}_ovs_usvhost would implement the usvhost support."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Alternatives"},{"line_number":30,"context_line":"------------"},{"line_number":31,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"baada198_6656055e","line":28,"in_reply_to":"baada198_e9ff6c65","updated":"2014-07-04 00:20:51.000000000","message":"We still rotate around the fact that yes, the binding type alone is sufficient to make the choice (and Przemyslaw, I would still use a different type; the behaviour on the Nova end is quite dramatically different) and yes, you need to be able to choose the binding type in Neutron rather than religiously choosing the same one every time.\n\nIf we can get past that second thing (Daniel appears to object to the mechanism of choice that BigSwitch had, not the choosing, and I\u0027m loosely in agreement with that) then I think we\u0027d be OK.","commit_id":"809c0d14a32203ec97ee7ef9a39d29911f3fd4a0"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"46cf5b363104007e489d800f97dc7791bd63521c","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_8bc7c111","line":39,"updated":"2014-07-18 08:40:48.000000000","message":"It makes much more sense to me to use a different binding_type, rather than details under an existing binding_type, particularly since (a) the behaviour is quite different and (b) a hypervisor might support OVS binding but not DPDK binding.  \n\nI raised this on the mailing list and got no answer.  Can you give a justification for your choice?","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"de7e752acca834b1f8dea8ddd7de374b037efb02","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_74f9cc4d","line":39,"in_reply_to":"baada198_221d8bbe","updated":"2014-07-22 16:18:57.000000000","message":"Thinking about this a little more, I\u0027m not too fussed on the VIF type name whether TYPE_CUSE or TYPE_DPDK, since I imagine DPDK is the only impl that\u0027s likely to ever use this hack - any new work will likely target the official QEMU vhost-user device instead.\n\nWhat I\u0027m  a little fuzzy on still is the impl details of this and how the choice between traditional VIF_TYPE_OVS and this new  VIF type is made. In the Neutron spec it is said \n\n  * If the node supports only kernel vhost VIF_TYPE_OVS will be used\n  * If the node supports dpdkvhost VIF_TYPE_VHOST_CUSE will be used.\n\nHow does Neutron know whether the compute node supports a particular type ?\n\nWe have discussed having Nova provide Neutron with a list of support VIF types when setting up ports, but that is not mentioned as part of the design in this spec.  Can you fill some more details of exactly how you\u0027re proposing this to work architecturally.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fbe2275709970c5463b5b6002b081f9b9904fe77","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_6cb2b84a","line":39,"in_reply_to":"baada198_221d8bbe","updated":"2014-07-23 12:06:31.000000000","message":"by DPDKovs are you referring to the standard userpace open vswich with dpdk support or the Intel (R) dpdk vswitch?\n\nstandard openvswitch currently has three in tree datapaths.\n\nthe standard Linux  kernel datapath i the most commonly used open vswitch datapath with the largest feature set.\n\nthe standard netdev data path is a mature userspace only datapath that has shipped as part of standard openvswitch for many releases. the netdev datapath is very portable and supports most of the feture of the kernel datapath. the netdev data path is less commonly used in production as it has poor physical switching performance due to the need to copy all packet into the vswitchd process for switching.\n\nthe newest datapath in the openvswitch master tree is the dpdk accelerated netdev datapath. this datapath is intended to be a high throughput replacement for standard netdev datapath. The dpdk accelerated netdev datapath uses the dpdk poll mode driver and dpdk libraries to remove this bottleneck in the standard netdev datapath. to my knowledge it is fully feature compatible with the standard netdev datapath. the main outstanding feature\nmissing from the netdev datapath is tunneling support as this is supported in the kernel datapath via the vxlan and gre kernel modules.\n\nthe Intel (R) dpdk vswitch is a reference switch that replaces the standard openvswitch linux datapath with ad dpdk accelerated userspace implementation. it shares the same vswitchd ovsdb and userspace tools as standard ovs and can therefor be managed in the same way.\n\nthis feature proposal is to enable use of the alternative qemu vhost implementation provided by dpdk that is expected to be available in both standard openvswitch and the Intel (R) dpdk vswitch in the juno cycle.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bd84c5d014f8f2e230103069a26d98864e1681bf","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_e1bc91b7","line":39,"in_reply_to":"baada198_2bbaff0a","updated":"2014-07-21 16:14:02.000000000","message":"hi by transparent i meant transparent to the tenant which i guess your solution would satisfy.\n\nthe approach of using a flag was based off how ovs_hybrid_plug is implemented. \n\novs_hybrid_plug informs Nova if the hybrid plugging\nstrategy for OVS should be used.Similarly ovs_use_dpdkvhost (or ovs_use_vhost_cuse) would inform nova if the dpdk userpace vhost  plugging strategy  should be used.\n\nin theory the same mechanism we are proposing in neutron could be used to select a VIF_TYPE instead of setting the flag. it would require altering the ovs and odl ml2 drivers to dynamically select the VIF_TYPE however the interface does allow this. \n\ni will add your suggestion to the neutron spec and ask for their input. if they are ok with this change i will update both spec to refelct that   VIF_TYPE_VHOSTCUSE will be set by neutron if the dpdk userpace vhost  plugging strategy  should be used.\n\nif neutron push back and prefer the flag be used would you still object if we changed the name to ovs_use_vhost_cuse?","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"748eef44d50c77500070ce9bb2741b31048fbffb","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_9760be36","line":39,"in_reply_to":"baada198_3c3c392f","updated":"2014-07-18 10:26:28.000000000","message":"This is tied strongly to both ovs and dpdk. As part of creating a binding a port has to be added to ovs with dpdkvhost port type.\nhttps://review.openstack.org/#/c/100256/1/nova/network/linux_net.py\nhence the name. We don\u0027t wan\u0027t to add a new vif_type just allow VIF_TYPE_OVS to connect to ovs with dpdk datapath. Vanilla ovs supports this. I don\u0027t mind changing the name, but i think it makes more sense as it is.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c53d9763a4bbdf710b1f4edccdc8077ca9bdf1f2","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_5a538615","line":39,"in_reply_to":"baada198_3c3c392f","updated":"2014-07-19 23:27:35.000000000","message":"i dont think  VIF_TYPE_VHOSTFUSE is appropriate as the FUSE (Filesystem in Userspace) module is not use as part of this implementation. if a generic vif type was to be used  VIF_TYPE_VHOSTCUSE  (Character device in Userspace) would be more correct.\n\ni do however feel that  adding a new vif or vnic is the wrong approach as the use of userspace vhost instead of kernel vhost is intended to be transparent.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ea8a0d38529242288a0220a7056f45a30e44059e","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_2bbaff0a","line":39,"in_reply_to":"baada198_5a538615","updated":"2014-07-20 23:56:45.000000000","message":"Define transparent.  There\u0027s no config required here more than changing the mechanism driver to use the correct binding type (versus changing the mechanism driver to use the same binding type but pass a magic flag to make it behave differently).  The tenant wouldn\u0027t know what was going on under the hood.  I don\u0027t see how either method is more onerous on admins, but one of these means that the VIF type means something different to what it did before, and also means that (in the future) a hypervisor that declares its supported VIF types would have to declare that yes, it supports OVS VIF types, but just not *that* sort of OVS VIF type.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bd03a93c8cc55817002ab740c3aa8049c6aaedde","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_e0cb2fa2","line":39,"in_reply_to":"baada198_6ff647fb","updated":"2014-07-23 11:44:06.000000000","message":"all ml2 drivers i am aware of bar 1 use hard coded VIF types and rely on the deployer to ensure the vswtich/bridge installed on the compute node is comparable with the hypervisor.\n\nthe ml2 driver are specified in order of preference via the \nmechanism_drivers \u003d openvswitch,mlnx...\n\nwhen booting a vm on a compute node it will use the first \nmechanism_driver that is supported on the node.\n\nfor sriov the following can be done\nneutron port-create --name sriov_port --vnic-type direct \u003cnet-uuid-from-step-1\u003e \n nova boot --flavor m1.large --image \u003cimage-uuid\u003e --nic port-id\u003d\u003cport-uuid-from step-3\u003e \n\nim not sure how running multiple l2 agent on a single compute node works but im not aware of a way to specify via horizon or the cli which backend you want to boot the vm with.\n\nthe only ml2 driver at present that support multiple vif types is  mech_mlnx.\nthe mech_mlnx mechanism driver uses the following function\n\ndef _get_vif_type(self, requested_vnic_type):\n        if requested_vnic_type \u003d\u003d portbindings.VNIC_MACVTAP:\n                return portbindings.VIF_TYPE_MLNX_DIRECT\n        elif requested_vnic_type \u003d\u003d portbindings.VNIC_DIRECT:\n                return portbindings.VIF_TYPE_MLNX_HOSTDEV\n        return self.vif_type\n\nnote that self.vif_type is set via the plugins conf file and is used for non siriov/pci pass though ports.\n\nthe bigswitch plugin takes a similar approach where  the default vif type is set in a conf and a vif override is set in the conf. this override involves adding the hostid of the a compute node to a comma separated list in the conf file.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"dad2c4a3bb2faccf8c40623c5431d3085514974c","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_917f4769","line":39,"in_reply_to":"baada198_74f9cc4d","updated":"2014-07-22 20:20:47.000000000","message":"determining if a node supports/requires  dpdk\u0027s implementation of vhost is a little complicated but there are a series of simple checks that can be done.\nThe reason for the initial approach of a nova config option was to avoid these checks however i accept that the config option would not be suitable for nova for the reasons you gave before.\n\nfirst the hypervisor must be determined.\nneutron would do this by quering the nova.compute_node table with the binding:host_id to select the hypervisor_type feild.\nthis can be done a number of way either directly via the db or via the nova cli. if the value is not QEMU VIF_TYPE_OVS will be used. \n\nif a list of supported vif types is passed to nova the above step can be skiped as the presence of the new vif type in the list will signal that the compute nodes hypervisor supports dpdkvhost. \n\nonce neutron determines that the hypervisor support the new vif_type by either of the above methods it will then check if the vswitch support or requires the dpdkvhost backend.\n\nthe first step is to  retrieve the datapath type of the integration bridge on the selected node compute node. this will be done either via odl or the ovs agent. if the datapath type is dpdk the intel (R) dpdk vswitch is present on the compute node so the new vif_type will be used. if the datapath is netdev and addtional check is performed. for any other value  VIF_TYPE_OVS will be used. \n\nif the value is netdev either the userspace open vswitch builid target is installed on the compute node or the dpdk enabled open vswitch build target is installed.\n\nthe only method currently to differentiate between these two build options of is to check the commandline the ovs-vswitchd process was launched with. if the commandline contains --dpdk the new vif will be used otherwise  VIF_TYPE_OVS will be used.\n\nas odl cannot preform this final check if the datapath is netdev  VIF_TYPE_OVS will be used.\n\nto simplfy detection in future openvswitch versions i am going to propose openvswitch mailing list that one of the follow 3 modification be made.\n\n1: the commandline fo the ovs-vswitchd process be stored in the ovsdb.(least preferable option)\n\n2: the datapath type of the dpdk build could be changed to netdev-dpdk (better but not optimal)\n\n3:extend the bridge table in the ovsdb with a supported_port_types field. when ovs-vswitchd starts it would update the support port type for each bridge based on the datapath type and the commandline it was launched with. (optimal solution)\n\nfor ovs with the kernel datapath the supported port types would be :\nkernel vhost, veth,physical\n\nfor ovs with dpdk the supported port types would be :\nkernel vhost, veth,physical,ivshrmem,dpdkvhost,dpdk\n\nfor intel\u0027s vswitch the supported port types would be :\nivshrmem,dpdkvhost,dpdk\n\nnote that dpdk means a dpdk physical port.\n this change is out of scope for juno and possibly kilo.\n\nthis would simplify the detection to two steps.\n1 determine hypervisor support as above.\n2 check if dpdkvhost is one of the supported port types of br-int","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":12051,"name":"loy","email":"loywolfe@gmail.com"},"change_message_id":"96b1c98b838892bd5b1a9060e91e55927435ba16","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_6ff647fb","line":39,"in_reply_to":"baada198_74f9cc4d","updated":"2014-07-23 00:36:15.000000000","message":"how do we determine vif type of ovs/linux bridge/sriov VEB/sriov qbh now? Think dpdkovs/snabb is just another type of switch backend, then a general unified solution is needed to deal with all these cases.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ee8cb4fc1dbe4563317fae90c1b1c52264e1b02d","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_90650fe3","line":39,"in_reply_to":"baada198_7c5b1122","updated":"2014-07-18 21:26:12.000000000","message":"You can\u0027t use mechanism drivers on the Neutron side without changing them to pass the additional parameter, so clearly the advantage here is not \u0027nothing in Neutron has to change\u0027.  If you\u0027re changing them, you could equally well change them to pass a different binding type, instead.\n\nSo, again, why would you not add an entirely new binding type?","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"11b9bb01144fd7ba4615a796b77f1a32ccd005a0","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_3c3c392f","line":39,"in_reply_to":"baada198_8bc7c111","updated":"2014-07-18 09:57:33.000000000","message":"I\u0027m not really a fan of using dpdk in the name because while DPDK is the primary user, it is certainly possible for other users to make use of the functionality.  As such I had previously suggest we name the VIF type based on its technical approach. ie call this VIF_TYPE_VHOSTFUSE, since Luke says this is using a FUSE module to replace the standard vhost-net device.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"40a10d6c9bc7f96e305b3a33bd5cc45c695a96a9","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_7c5b1122","line":39,"in_reply_to":"baada198_8bc7c111","updated":"2014-07-18 09:44:45.000000000","message":"This approach allows reuse of  existing mechanism drivers and agents on neutron side. Additional information passed by neutron will ensure hypervisor/Open vSwitch compatibility.Currently in ovs bindings behaviour is chosen depending on different factors, in a way similar to what we propose.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"ee8cb4fc1dbe4563317fae90c1b1c52264e1b02d","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_d0b22748","line":39,"in_reply_to":"baada198_9760be36","updated":"2014-07-18 21:26:12.000000000","message":"We got Luke to change the VHOSTUSER from SNABB for similar reasons, and I think the change Daniel asked for is in keeping.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c53d9763a4bbdf710b1f4edccdc8077ca9bdf1f2","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_3a17b2a4","line":39,"in_reply_to":"baada198_d0b22748","updated":"2014-07-19 23:27:35.000000000","message":"assuming  your objections to the use of dpdk in the names of functions or variables  \novs_use_dpdkvhost could be changed to ovs_use_vhost_cuse\n\nsimilarly {get_config, plug, unplug}_ovs_dpdkvhost could be changed to {get_config, plug, unplug}_ovs_vhost_cuse.\n\ni do however belive that dpdkvhost is more suitable.\n\nmy reasoning for this is as follows\n\nfirst, since the release of userspace vhost in dpdk 1.6 in February  userspace vhost has been used to refer to the dpdk implementation in the openvswitch and dpdk communities. \n\nfor this reason to prevent confusion with the snabb implementation and qemu\u0027s new vhost-user interface dpdkvhost was chosen instead of uservhost. \n\nsecondly  dpdkvhost is the name of the port type used in the intel dpdk vswitch and this port type will also be used in standard openvswitch as mentioned above.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":12051,"name":"loy","email":"loywolfe@gmail.com"},"change_message_id":"4bb1bc8a3963d30eae837a6435af0dd4800f98e0","unresolved":false,"context_lines":[{"line_number":36,"context_line":"{get_config, plug, unplug}_ovs  depending on the value of ovs_use_dpdkvhost"},{"line_number":37,"context_line":"variable. ovs_use_dpdkvhost will be passed in binding:vif_details by neutron."},{"line_number":38,"context_line":"The {get_config, plug, unplug}_ovs_dpdkvhost would implement the dpdkvhost"},{"line_number":39,"context_line":"support."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":2,"id":"baada198_221d8bbe","line":39,"in_reply_to":"baada198_e1bc91b7","updated":"2014-07-22 02:47:50.000000000","message":"Either dpdkovs or snabb stands for a trend of userspace high performance vswitchs. When we implement it, we can choose to fork with ovs, or green built. However, they should be separated from existing bridge type, else if someone would implement another fork of ovs in the future, etc, ABC-ovs, should he also request adding ovs_use_vhost_ABC flag in the ovs vif plug driver once more?\n\nAlso, we should give user the freedom of hybrid deployment in each host: put some traffic on one bridge, some traffic on other bridge, just like ovs/linuxbridge/macvtap/sriov..today. dpdkovs/snabb should add to the family, but not exclusive with one of them and force the user to choose which one should be used in each host.\n\nReuse mech_driver should not be the key factor. Any new backend bridge has their own mech_driver. XXXX_user_ovs just looks like ovs, but it is not the real kernel ovs(in fact they can not fully replace ovs even by features, not to say stability in production environment). In a host, we can host only one kernel ovs instance, but can host many userspace forked ovs instances currently.","commit_id":"4870e7e15ffe33558a26f799249bc72506680d2f"},{"author":{"_account_id":12051,"name":"loy","email":"loywolfe@gmail.com"},"change_message_id":"8590248673638e4d2ae10aa7ab1d2ea1394ef7ee","unresolved":false,"context_lines":[{"line_number":17,"context_line":"standard qemu vhost interface for qemu versions \u003c2.0"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The Intel(R) DPDK Userspace implemention of the vHost backend uses the CUSE"},{"line_number":20,"context_line":"kernel module to replace the standard /dev/vhost-net character device"},{"line_number":21,"context_line":"with a userspace character device to intercept ioctls from QEMU."},{"line_number":22,"context_line":"This allows the standard vhost interface to be used"},{"line_number":23,"context_line":"with userspace only vswitches."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_c38c59da","line":20,"updated":"2014-07-24 00:35:40.000000000","message":"to replace-\u003einstead of\n\nwill \"replace\" has some misleading that when CUSE is used, then standard vhost-net will be removed? In fact CUSE can co-exist with vhost-net","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7f71c4fd5dc56733d322870a47de99a10d402a2","unresolved":false,"context_lines":[{"line_number":17,"context_line":"standard qemu vhost interface for qemu versions \u003c2.0"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The Intel(R) DPDK Userspace implemention of the vHost backend uses the CUSE"},{"line_number":20,"context_line":"kernel module to replace the standard /dev/vhost-net character device"},{"line_number":21,"context_line":"with a userspace character device to intercept ioctls from QEMU."},{"line_number":22,"context_line":"This allows the standard vhost interface to be used"},{"line_number":23,"context_line":"with userspace only vswitches."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_a2fcb4b6","line":20,"in_reply_to":"baada198_14fd9e6e","updated":"2014-07-24 08:59:12.000000000","message":"using a different device it supported only in the port to standard ovs. i will talk to the maintianers of both dpdkvhost impementations today do evaluate the full extent of the changes required to support this.\n\nwhat i do know at a high level is that it would require generating a different libvirt xml for vms that dont use /dev/vhost net and a wrapper script for qemu would be needed to open different file dicripters then the ones provided by libvirt.\n\nthis complicates the impementation and dection mechanisium somewaht but i\nwill investaget to determing how much.\n\ndpdkvhost was originally intended to be a transparent replacement for kernel vhost as such this useage model is not the one we intended to support.\nalso note that kernel vhost dose not work with the intel (R) dpdk  vswitch.","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8dce3bee85e5c0a05a617ad153a892201e5d7c76","unresolved":false,"context_lines":[{"line_number":17,"context_line":"standard qemu vhost interface for qemu versions \u003c2.0"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The Intel(R) DPDK Userspace implemention of the vHost backend uses the CUSE"},{"line_number":20,"context_line":"kernel module to replace the standard /dev/vhost-net character device"},{"line_number":21,"context_line":"with a userspace character device to intercept ioctls from QEMU."},{"line_number":22,"context_line":"This allows the standard vhost interface to be used"},{"line_number":23,"context_line":"with userspace only vswitches."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_383ff0b6","line":20,"in_reply_to":"baada198_483db92b","updated":"2014-07-24 11:40:31.000000000","message":"hi can your clearly define what you mean by dpdkovs and OVS.\n\ni have avoided the use of dpdkovs as it is not clear of you mean the Intel (R) DPDK vSwitch or the DPDK Build of standard OVS maintained at Openvswitch.org  and implemented here\nhttps://github.com/openvswitch/ovs/blob/e9fe2381ec863f85eb766ed5d309e22146d2fb04/lib/netdev-dpdk.c\n\nwhile the co-existence has some advantage i think the cleanest approach is still to have separate nodes and use available zones to manage the co-existence.","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":12051,"name":"loy","email":"loywolfe@gmail.com"},"change_message_id":"c1598f22133963e217aa4de83ff24f4ccc55d4c6","unresolved":false,"context_lines":[{"line_number":17,"context_line":"standard qemu vhost interface for qemu versions \u003c2.0"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The Intel(R) DPDK Userspace implemention of the vHost backend uses the CUSE"},{"line_number":20,"context_line":"kernel module to replace the standard /dev/vhost-net character device"},{"line_number":21,"context_line":"with a userspace character device to intercept ioctls from QEMU."},{"line_number":22,"context_line":"This allows the standard vhost interface to be used"},{"line_number":23,"context_line":"with userspace only vswitches."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_483db92b","line":20,"in_reply_to":"baada198_a2fcb4b6","updated":"2014-07-24 10:02:20.000000000","message":"if we really want dpdkovs to be successful and find their place in production environment, it\u0027s better not to positioned as replacement for kernel vhost. Starting applications of higher performance but less feature requirement, will be easier and smoothly.\n\nMore work is needed with co-exist, but the good news is that it do not bother any existing system and deployment. Any dpdkovs and XXXXovs should not be treated as OVS itself.","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":7916,"name":"Luke Gorrie","email":"luke@snabb.co","username":"lukego"},"change_message_id":"47bfba7d259fc4cffcf5af99f13e1426161ff05e","unresolved":false,"context_lines":[{"line_number":17,"context_line":"standard qemu vhost interface for qemu versions \u003c2.0"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The Intel(R) DPDK Userspace implemention of the vHost backend uses the CUSE"},{"line_number":20,"context_line":"kernel module to replace the standard /dev/vhost-net character device"},{"line_number":21,"context_line":"with a userspace character device to intercept ioctls from QEMU."},{"line_number":22,"context_line":"This allows the standard vhost interface to be used"},{"line_number":23,"context_line":"with userspace only vswitches."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_14fd9e6e","line":20,"in_reply_to":"baada198_c38c59da","updated":"2014-07-24 08:01:49.000000000","message":"That is awesome that CUSE and kernel vhost-net can co-exist peacefully. I would definitely highlight that. I had assumed this was an either-or choice for the deployer i.e. that deploying the CUSE support would require disabling vhost on QEMU ports that do not connect to the DPDK.","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"474bb1c27154ee325c5336bb77f29906f025a797","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Add {get_config, plug, unplug}_ovs_vhost_cuse methods to"},{"line_number":38,"context_line":"LibvirtGenericVIFDriver. Those methods would be called from"},{"line_number":39,"context_line":"{get_config, plug, unplug}_ovs  if the vif_type is VIF_TYPE_VHOST_CUSE. "},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The {get_config, plug, unplug}_ovs_vhost_cuse will implement dpdkvhost"},{"line_number":42,"context_line":"support."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_17984069","line":39,"updated":"2014-07-24 08:39:39.000000000","message":"I am not sure it would work.\nYou probably will have to keep vif_type VIF_OVS and add extra info in vif_details. Now the libvirt generic vif driver, bdoe not have if else clauses on vif_type, but constructs it from received vif_type.\nOr your method will be called without entering into {get_config, plug, unplug}_ovs.","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7f71c4fd5dc56733d322870a47de99a10d402a2","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Add {get_config, plug, unplug}_ovs_vhost_cuse methods to"},{"line_number":38,"context_line":"LibvirtGenericVIFDriver. Those methods would be called from"},{"line_number":39,"context_line":"{get_config, plug, unplug}_ovs  if the vif_type is VIF_TYPE_VHOST_CUSE. "},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The {get_config, plug, unplug}_ovs_vhost_cuse will implement dpdkvhost"},{"line_number":42,"context_line":"support."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_a2c11450","line":39,"in_reply_to":"baada198_17984069","updated":"2014-07-24 08:59:12.000000000","message":"hi sorry that should be {get_config, plug, unplug}_ovs_vhost_cuse not {get_config, plug, unplug}_ovs \n\ni will make this change when i remove the trailing spaces","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":3217,"name":"Ian Wells","username":"ijw-ubuntu"},"change_message_id":"c3f8de526d6a6b000811655ce406aac2aa84a329","unresolved":false,"context_lines":[{"line_number":98,"context_line":"Performance Impact"},{"line_number":99,"context_line":"------------------"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Userspace vHost was developed to enable high-throughput workloads without "},{"line_number":102,"context_line":"modifications to QEMU or the guest VMs."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"For performance measurements based on Intel(R) DPDK Accelerated vSwitch"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_e304071b","line":101,"updated":"2014-07-23 18:45:07.000000000","message":"Nit: trailing spaces all over","commit_id":"6039b37112b33227758fed3fade28a98ad4644b7"},{"author":{"_account_id":12051,"name":"loy","email":"loywolfe@gmail.com"},"change_message_id":"dc3b95dd7835139afb2759d3b0c359256816927d","unresolved":false,"context_lines":[{"line_number":33,"context_line":"Proposed change"},{"line_number":34,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":35,"context_line":"A new vif_type VIF_TYPE_VHOST_CUSE will be added to support dpdkvhost."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Add {get_config, plug, unplug}_ovs_vhost_cuse methods to"},{"line_number":38,"context_line":"LibvirtGenericVIFDriver."},{"line_number":39,"context_line":"{get_config, plug, unplug}_ovs_vhost_cuse will be called"}],"source_content_type":"text/x-rst","patch_set":4,"id":"baada198_a1ac8f36","line":36,"updated":"2014-07-25 01:47:02.000000000","message":"it\u0027 ok here, and I\u0027ll put comments on another ML2 spec, about vif detect and argument with co-existence vs. drop-in replacement.\n\nBTW, any difference of vif-plug when 1:1 for vnic and VF? It may bring zero-copy, if VF DMA buf is set with vring buf address directly, but not with pre-allocated buf by dpdkovs initialization. In dpdk material, 64b has nearly 7Mpps but 1500b has only 1.7Mpps, so zero-copy may improve 1500b packet throughput to fill a whole 40GE link.","commit_id":"8a1092b88694460a4fc661625cc7a919ad152f3a"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"0f1a7db922ff639354b24ef9fdaabf8207b05771","unresolved":false,"context_lines":[{"line_number":52,"context_line":"Alternatives"},{"line_number":53,"context_line":"------------"},{"line_number":54,"context_line":"1:"},{"line_number":55,"context_line":"in addtion to the above changes the LibvirtGenericVIFDriver"},{"line_number":56,"context_line":"can be extended to pass a list of supported vif_types to neutron."},{"line_number":57,"context_line":"this removes the need for neutron to determine if the hypervisor supports"},{"line_number":58,"context_line":"the new vif_type but requires nova to maintian a list of all vif_types"}],"source_content_type":"text/x-rst","patch_set":4,"id":"baada198_70f30909","line":55,"updated":"2014-07-25 15:11:54.000000000","message":"Typo: addition","commit_id":"8a1092b88694460a4fc661625cc7a919ad152f3a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6aad5f23d5f0b1a8ac2c50c642c50527a5bce343","unresolved":false,"context_lines":[{"line_number":52,"context_line":"Alternatives"},{"line_number":53,"context_line":"------------"},{"line_number":54,"context_line":"1:"},{"line_number":55,"context_line":"in addtion to the above changes the LibvirtGenericVIFDriver"},{"line_number":56,"context_line":"can be extended to pass a list of supported vif_types to neutron."},{"line_number":57,"context_line":"this removes the need for neutron to determine if the hypervisor supports"},{"line_number":58,"context_line":"the new vif_type but requires nova to maintian a list of all vif_types"}],"source_content_type":"text/x-rst","patch_set":4,"id":"baada198_2a8bdd69","line":55,"in_reply_to":"baada198_70f30909","updated":"2014-07-25 17:18:21.000000000","message":"if they would not block spec approval i would like to wait until there are more changes to revise the spec.\n\notherwise i will revise on Monday with any other feedback.","commit_id":"8a1092b88694460a4fc661625cc7a919ad152f3a"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"0f1a7db922ff639354b24ef9fdaabf8207b05771","unresolved":false,"context_lines":[{"line_number":56,"context_line":"can be extended to pass a list of supported vif_types to neutron."},{"line_number":57,"context_line":"this removes the need for neutron to determine if the hypervisor supports"},{"line_number":58,"context_line":"the new vif_type but requires nova to maintian a list of all vif_types"},{"line_number":59,"context_line":"supprted by each hypervisor."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"see the following post for more details:"},{"line_number":62,"context_line":"http://lists.openstack.org/pipermail/openstack-dev/2014-July/039853.html"}],"source_content_type":"text/x-rst","patch_set":4,"id":"baada198_f04c7941","line":59,"updated":"2014-07-25 15:11:54.000000000","message":"Typo: supported","commit_id":"8a1092b88694460a4fc661625cc7a919ad152f3a"},{"author":{"_account_id":6598,"name":"Berezovsky Irena","email":"irenab.dev@gmail.com","username":"irenab"},"change_message_id":"0f1a7db922ff639354b24ef9fdaabf8207b05771","unresolved":false,"context_lines":[{"line_number":144,"context_line":"Testing"},{"line_number":145,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Unit tests will be added to test added code."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Documentation Impact"},{"line_number":150,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"baada198_b01be11a","line":147,"updated":"2014-07-25 15:11:54.000000000","message":"Is there any external CI planned for verification?","commit_id":"8a1092b88694460a4fc661625cc7a919ad152f3a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6aad5f23d5f0b1a8ac2c50c642c50527a5bce343","unresolved":false,"context_lines":[{"line_number":144,"context_line":"Testing"},{"line_number":145,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Unit tests will be added to test added code."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Documentation Impact"},{"line_number":150,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"baada198_df8301c9","line":147,"in_reply_to":"baada198_b01be11a","updated":"2014-07-25 17:18:21.000000000","message":"hi at present we are not planning to have a dedicated CI for this feature as the vif code is almost identical to standard ovs.","commit_id":"8a1092b88694460a4fc661625cc7a919ad152f3a"}]}