)]}'
{"specs/kilo/approved/libvirt_vif_vhostuser.rst":[{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"988828dc1e98eedf06000faebdf05d8e6fcb41d4","unresolved":false,"context_lines":[{"line_number":45,"context_line":"interfaces based on vhost-user. This VIF type would be enabled by"},{"line_number":46,"context_line":"Neutron drivers by using portbindings extension and setting the"},{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_detail."},{"line_number":49,"context_line":"For ovs based vSwitches additional step of creating an ovs port"},{"line_number":50,"context_line":"will be performed by the libvirt driver."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_fd272fb4","line":48,"updated":"2014-12-10 09:43:17.000000000","message":"It seems to be a pretty good idea to share the same code for\ngeneric/ovs switches. The idea is really similar with vif-type-tap\nspec for vhost-net.\n\nWhich portbindings extensions are you going to use for VIF_VHOSTUSER?\n\nNormally get_config, plug, unplug methods are selected considering the\nVIF_TYPE, how will it work with VIF_VHOSTUSER to choose between\ngeneric and ovs switch?","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11785,"name":"henry.hly","email":"henry4hly@gmail.com","username":"hly"},"change_message_id":"33d5b9435dd7795b090eb22918c93bcee1149410","unresolved":false,"context_lines":[{"line_number":45,"context_line":"interfaces based on vhost-user. This VIF type would be enabled by"},{"line_number":46,"context_line":"Neutron drivers by using portbindings extension and setting the"},{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_detail."},{"line_number":49,"context_line":"For ovs based vSwitches additional step of creating an ovs port"},{"line_number":50,"context_line":"will be performed by the libvirt driver."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_03bbb9c4","line":48,"in_reply_to":"3a961159_685a9c51","updated":"2014-12-10 12:42:24.000000000","message":"If nova is responsible for ovs plug, then it\u0027s not really same as vif-type-tap. tap-vif make no suppose whatever backend switch is, libvirt just leave a tap device in the system, and neutron agent can plug it on any switch you like.\n\nSee comment below, if socket is created by libvirt, then they would have the same model","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"3f50dc91ff763ff7fb90f632e65a24d38d09c52f","unresolved":false,"context_lines":[{"line_number":45,"context_line":"interfaces based on vhost-user. This VIF type would be enabled by"},{"line_number":46,"context_line":"Neutron drivers by using portbindings extension and setting the"},{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_detail."},{"line_number":49,"context_line":"For ovs based vSwitches additional step of creating an ovs port"},{"line_number":50,"context_line":"will be performed by the libvirt driver."},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_685a9c51","line":48,"in_reply_to":"3a961159_fd272fb4","updated":"2014-12-10 12:14:20.000000000","message":"Neutron mechanism drivers will pass a flag in portbinding.vif_details. \nThe presence of this flag will be checked in plug and unplug, and ovs ports will be added removed depending on it.\nAnother flag will be passed in vif_details to specify if qemu is the server or client.","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"988828dc1e98eedf06000faebdf05d8e6fcb41d4","unresolved":false,"context_lines":[{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_detail."},{"line_number":49,"context_line":"For ovs based vSwitches additional step of creating an ovs port"},{"line_number":50,"context_line":"will be performed by the libvirt driver."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will assume that unix socket will be created"},{"line_number":53,"context_line":"by the vSwitch per Neutron port. The name of the socket will be the"},{"line_number":54,"context_line":"same as ID of the Neutron port. For ovs based vSwitches name of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_fd4e4f6e","line":51,"updated":"2014-12-10 09:43:17.000000000","message":"Which specific steps are needed? Is it only for plug/unplug methods to\nadd/remove the interface in the ovs bridge?","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"3f50dc91ff763ff7fb90f632e65a24d38d09c52f","unresolved":false,"context_lines":[{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_detail."},{"line_number":49,"context_line":"For ovs based vSwitches additional step of creating an ovs port"},{"line_number":50,"context_line":"will be performed by the libvirt driver."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will assume that unix socket will be created"},{"line_number":53,"context_line":"by the vSwitch per Neutron port. The name of the socket will be the"},{"line_number":54,"context_line":"same as ID of the Neutron port. For ovs based vSwitches name of the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_8878a8f3","line":51,"in_reply_to":"3a961159_fd4e4f6e","updated":"2014-12-10 12:14:20.000000000","message":"yes, that\u0027s only thing thats needed.","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"94b062fa419baaf779b0a4b66b6ac63ff78947e7","unresolved":false,"context_lines":[{"line_number":52,"context_line":"VIF_VHOSTUSER driver will assume that unix socket will be created"},{"line_number":53,"context_line":"by the vSwitch per Neutron port. The name of the socket will be the"},{"line_number":54,"context_line":"same as ID of the Neutron port. For ovs based vSwitches name of the"},{"line_number":55,"context_line":"socket will be the same as name of the ovs port."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Alternatives"},{"line_number":58,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_3ddff73c","line":55,"updated":"2014-12-10 09:37:08.000000000","message":"Do you really mean that the vSwitch will create the actual UNIX socket \u0026 QEMU will connect to that ?  IMHO it is better if Neutron merely specify the desired path for the UNIX socket, have QEMU create \u0026 listen on it and then the vSwitch connect to it.\n\nThis leads to a more robust system. If the vSwitch creates the socket, then if you need to restart the vSwitch software (eg for an upgrade) you kill every single running VM.  If QEMU creates the socket, then if you restart the vSwitch software it can reconnect to QEMU and you merely have a small temporary network traffic outage.","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"2515ecb67e7f8a23115a8b3609ba3b085928c34b","unresolved":false,"context_lines":[{"line_number":52,"context_line":"VIF_VHOSTUSER driver will assume that unix socket will be created"},{"line_number":53,"context_line":"by the vSwitch per Neutron port. The name of the socket will be the"},{"line_number":54,"context_line":"same as ID of the Neutron port. For ovs based vSwitches name of the"},{"line_number":55,"context_line":"socket will be the same as name of the ovs port."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Alternatives"},{"line_number":58,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_d9836054","line":55,"in_reply_to":"3a961159_039ad913","updated":"2014-12-10 13:15:48.000000000","message":"I think we also have to support the case when it\u0027s the vSwitch that creates the socket.\n\nRegarding the vif type plug mechanism i think it\u0027s still needed even if tap and vhostuser are in. There are things like sriov, macvtap, ivshmem, memnics that are not covered by the tap and vhostuser drivers.","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"3f50dc91ff763ff7fb90f632e65a24d38d09c52f","unresolved":false,"context_lines":[{"line_number":52,"context_line":"VIF_VHOSTUSER driver will assume that unix socket will be created"},{"line_number":53,"context_line":"by the vSwitch per Neutron port. The name of the socket will be the"},{"line_number":54,"context_line":"same as ID of the Neutron port. For ovs based vSwitches name of the"},{"line_number":55,"context_line":"socket will be the same as name of the ovs port."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Alternatives"},{"line_number":58,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_68229c02","line":55,"in_reply_to":"3a961159_3ddff73c","updated":"2014-12-10 12:14:20.000000000","message":"Yes you are right. \nThe vif driver should make no assumption on who will create the socket and allow the mechanism drivers to specify what they want.\nI\u0027ll update the spec to reflect that.","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11785,"name":"henry.hly","email":"henry4hly@gmail.com","username":"hly"},"change_message_id":"33d5b9435dd7795b090eb22918c93bcee1149410","unresolved":false,"context_lines":[{"line_number":52,"context_line":"VIF_VHOSTUSER driver will assume that unix socket will be created"},{"line_number":53,"context_line":"by the vSwitch per Neutron port. The name of the socket will be the"},{"line_number":54,"context_line":"same as ID of the Neutron port. For ovs based vSwitches name of the"},{"line_number":55,"context_line":"socket will be the same as name of the ovs port."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Alternatives"},{"line_number":58,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_039ad913","line":55,"in_reply_to":"3a961159_68229c02","updated":"2014-12-10 12:42:24.000000000","message":"As I commented difference about vhostuser and tap, if socket is created by libvirt, then it will be the same model as vif-type-tap. Any Neutron agent can plug it to related backend switch.\n\nHowever, I suggest that the desired path is not created by Neutron, but as the pre-configured well-known name between nova and neutron, e.g. /path/sockdir/vhostuser-br-int/ :) Then neutron L2 agent can scan in this directory, very similar with br-int port scan.\n\nBy this way, no vif driver plug mechanism is needed any more [#136827], because vif-type-vhostuser don\u0027t understand any backend switch implementation, the same as vif-type-tap. So nova just need to approve the two new general vif type (vhostuser \u0026 tap), do not twist with Neutron side switch backend","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"988828dc1e98eedf06000faebdf05d8e6fcb41d4","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An ml2 dpdk ovs driver is being proposed for Neutron."},{"line_number":138,"context_line":"This feature doesn\u0027t directly depend on it."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Testing"},{"line_number":141,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_dd47d349","line":139,"updated":"2014-12-10 09:43:17.000000000","message":"Vhost-user needs hugepages for the vm. Should we add the following dependency with this blueprint: https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages?","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"3f50dc91ff763ff7fb90f632e65a24d38d09c52f","unresolved":false,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"An ml2 dpdk ovs driver is being proposed for Neutron."},{"line_number":138,"context_line":"This feature doesn\u0027t directly depend on it."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Testing"},{"line_number":141,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":142,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a961159_c832b00f","line":139,"in_reply_to":"3a961159_dd47d349","updated":"2014-12-10 12:14:20.000000000","message":"Yes i\u0027ll add a dependency","commit_id":"735db33b5f1ce0bbf2ae64371747c26852cb72a6"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"c230783e17a3ea271b92a03caec09b44dec536b6","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_b6f6058f","line":50,"updated":"2014-12-15 21:25:09.000000000","message":"@henry.hly +1 to point 1\n\n@Sean Mooney: Agreed with henry.hly. First step implementing vhost-user\nin nova for generic switch. For the second step for ovs dpdk, we will\nsee if the vif_plug_script feature is ready or not. Else we still can\nuse \u0027vhost_user_ovs_plug\u0027 portbinding option.\n\nAnyway, the spec has been merged. Good job guys ;)","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"cb6482cb92ef8e47fb6dc38d3910ff8db04799de","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_49604da5","line":50,"updated":"2014-12-11 17:28:59.000000000","message":"For a tenant, you can have both use-cases: a vm with high performance network ports (i.e. vhost-user) or just a vm with standard network port (i.e. vhost-net).\n\nAgreed with your point, VIF_TYPE_TAP cannot be used for vhost-user, it doesn\u0027t make sense.\n\nBut instead, to have \u0027vhost_user_ovs_plug\u0027, I prefer the idea of Daniel\nBerrange to have a vif_plug_script option in the port bindings of the ML2.\n\nSee http://lists.openstack.org/pipermail/openstack-dev/2014-December/052744.html\n\nExample for:\n\n- for snabb switch: vif_type\u003dvhostuser, vif_plug_script\u003dnone\n- for dpdk ovs: vif_type\u003dvhostuser, vif_plug_script\u003d/usr/bin/neutron-dpdk-ovs-vif-plug","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":13869,"name":"Maxime Leroy","email":"maxime.leroy@6wind.com","username":"mleroy"},"change_message_id":"c22c93ec79af95dac40b8ed4b1d02d3df4be4121","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_d76f9dc3","line":50,"updated":"2014-12-10 17:35:37.000000000","message":"We should not have a new key in vif_details to tell to plug/unplug in ovs.\nThe VIF_TYPE_OVS already gives this information.\n\nInstead to have a new VIF_TYPE_VHOSTUSER, we should reuse VIF_TYPE_OVS\nfor vhostuser ovs, VIF_TYPE_TAP for generic vhostuser vswitch.\n\nWe can add a new value in vnic_type\u003duserspace  for virtual nic driver\nin userspace, like vhostuser. It could be reused for other userspace\nvnics like memnic.\n\nIn this case, we should have:\n- VIF_TYPE_TAP and vnic_type\u003dnormal --\u003e vhost-net with noplug\n- VIF_TYPE_TAP and vnic_type\u003duserspace --\u003e vhost-userspace with noplug\n- VIF_TYPE_OVS and vnic_type\u003dnormal --\u003e vhost-net with ovs bridge\n- VIF_TYPE_OVS and vnic_type\u003duserspace --\u003e vhost-userspace with ovs bridge","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3384e07de41e7f4d93fa546c7ec88fc2aa47df57","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_aa96fc49","line":50,"in_reply_to":"3a961159_07a54946","updated":"2014-12-11 20:32:14.000000000","message":"@henry.hly\nthe usage model we are trying to enable for vhost-user with ovs, \nis where the datapath of the br-int is set to netdev during deployment. \nThis was enabled in the juno cycle in devstack by this change https://review.openstack.org/#/c/99447/ \n\n@Maxime Leroy\na vif_plug_script parameter raises alot of questions regarding the nova and neutron implementation.\ncan a neutron pass any string or just a path? a filesystem path or a generic url?\nis it a bash script? python? a python module that is imported with a a plug function? \ni agree with Przemek that using importlib to import plug unplug functions would be cleaner the passing parameters to a script.\n\ni dont think vif_plug_script\u003d/usr/bin/neutron-dpdk-ovs-vif-plug is a good way to enable extensibility of  vif plugging \nat this time, as no stable standardized interface exists in neutron. without a well defiended interface and with the\nsplit of neutron drivers/plugins out of tree, this is a recipe for compatibility issues.\n\nWhile i\u0027m not entirely against the idea in principal, i believe this will be very hard to test. \nThis would also complicate deployment as configuration of the path would depend on how openstack is packaged/installed.\neg one distro installs the file to /usr/bin and another to /usr/sbin or /usr/lib/...\n\nwhile i do think this might be a good addition to nova as it would reduce the need for new vif types, \ni would like to see a separate spec for how vif_plug_script would work and a definition of the nova and neutron api first.  \ni believe that is out of this spec and should be done independently.","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"dd9652e43315ad2241054a74bb095988170dca61","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_c37f9f64","line":50,"in_reply_to":"3a961159_127bb328","updated":"2014-12-12 11:36:11.000000000","message":"@henry.hly\n+1 to point 1\n\nfor point 2  un like ovdk with aovs(ovs + dpdk netdev datapath) you can use non dpdk accelerated ports(tap devices, physical ports ...) with the dpdk netdev datapath.\nas far as i am aware you can connect non dpdk physical ports to the dpdk netdev datapath.\n\nyou can also run some bridges with the linux kernel datapath and connect them to the netdev datapath via a veth pair.As the bridges have different datapaths, patch ports will not work. in this case your performance is limited to the performance of the veth pair. this may allow for features such as vxlan to work before native support in the netdev datapath however that is speculation as i have not tested that configuration.","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":11785,"name":"henry.hly","email":"henry4hly@gmail.com","username":"hly"},"change_message_id":"264e780ac1c745e8a669b4b6f77b95c56dd738e9","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_d16a3eed","line":50,"in_reply_to":"3a961159_309f0752","updated":"2014-12-11 01:24:22.000000000","message":"+1 that vif-type-tap could not be used for vhostuser, for their libvirt behavior is totally different, and vnic-type is not used for vif-plug.\n\nOn the other hand, are you sure that there exists standard for the ovs-dpdk like userspace datapath plug:\n\nIn a typical production environment, there would be at least two or more \"switching plane\" for traffic, E.g. one for management \u0026 storage, one for VM data traffic. While the latter could use vhostuser to gain performance, the former usually still run on default kernel ovs. So, the default ovs-vsctl command without any parameter would point to default \"system\" datapath, and userspace ovs port plug CLI should have their own parameter, which is different by end user deployment configuration. \n\nSo, unless default ovs system datapath is prohibited and replaced by a userspace datapath, the nova vif plug is impossible to be standardized.\n\nBy contract of Nova and Neutron, there is br-int on system datapath as the well-known integration point. So, now we also first need a standard bridge name and vsctl cli parameter entry for the userspace datapath.","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":11647,"name":"Przemyslaw Czesnowicz","email":"przemyslaw.czesnowicz@intel.com","username":"pczesno"},"change_message_id":"85b2a8c2dd8bfbd842a37a1cf0c4b405691fcc7b","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_07a54946","line":50,"in_reply_to":"3a961159_49604da5","updated":"2014-12-11 20:12:38.000000000","message":"It\u0027s probably better to pass module names and use importlib to import plug unplug functions.\nParameters would have to be passed to the script/functions and those would have to be standardized at least across the vif_type.\nBut in general this doesn\u0027t sound like a bad idea, and something we could use if libvirt driver decides to go this way.","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":11785,"name":"henry.hly","email":"henry4hly@gmail.com","username":"hly"},"change_message_id":"b862e6d5fd0ec672751c85c275c4cd32c5e13a8b","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_127bb328","line":50,"in_reply_to":"3a961159_aa96fc49","updated":"2014-12-12 10:00:23.000000000","message":"1. we can move forward step by step. First, let\u0027s introduce vif-type-tap and vif-type-vhostuser immediately, without extra script or plug drivers. I think a lot of use cases can be covered; Next, we can discuss script or lib import for additional plug action.\n\n2. yes you can set br-int to netdev, but how about if I have two br-eth, one for NIC with dpdk driver, one for NIC without DPDK driver?","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0f82c776e298798edb6fe18fd3de6d682fef1b0e","unresolved":false,"context_lines":[{"line_number":47,"context_line":"vif_type to VIF_VHOSTUSER. To support both generic and ovs based"},{"line_number":48,"context_line":"vSwitches additional information will be passed in vif_details."},{"line_number":49,"context_line":"For ovs based vSwitches plug/unplug methods will create/remove"},{"line_number":50,"context_line":"an ovs port if \u0027vhost_user_ovs_plug\u0027 is set to True in the vif_details."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify"},{"line_number":53,"context_line":"if qemu should work in server or client mode. Mechanism drivers"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a961159_309f0752","line":50,"in_reply_to":"3a961159_d76f9dc3","updated":"2014-12-10 19:26:26.000000000","message":"vhost-user vs kernel vhost is a implementation detail that should not be exposed to the tenant but rather a deployment decision made by the operator.\n\nFrom a tenants point of view there should be no difference between a vm booted with kernel vhost and vhost-user. a vhost-user nic is still a virtio-net interface and is indistinguishable from a nic with the kernel vhost back end.\nas such selecting a vnic would not make sense.\n\ni do not believe that using \"VIF_TYPE_TAP for generic vhostuser vswitch\" is correct as the name is misleading.\n\nyour example \n\"VIF_TYPE_TAP and vnic_type\u003duserspace --\u003e vhost-userspace with no plug\"\n\nis confusing as you are using a vif which has tap in its name to boot a vm without a tap device.\n\ni am bias as i am writing the neutron side but i believe that vif_detials provide a cleaner way of expressing this information then using VIF_TYPE_TAP and VIF_TYPE_OVS with an new vnic type.","commit_id":"1302e5ff7d075b5b73a2e17428eb8eabb3d92647"}]}