[ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace tunneling support in OVN-Openstack integration.
sugesh.chandran at intel.com
Thu Aug 27 16:56:56 UTC 2015
Thank you all for the comments and inputs.
we will cross-port this thread on openstack mailing list and see what needs to be done.
Another change we proposed in this patch set is adding support for new bridge(br-phy) in OVN.
Please refer the “[PATCH 3/4] ovn-controller: Controller man page modification for DPDK/userspace tunneling support in OVN-Openstack integration.” for more details.
To support for DPDK port/userspace tunneling, OVN needs to create and manage a new bridge along with integration bridge.
We are proposing to add this information in the OpenvSwitch table and update OVN controller code to manage this new bridge.
From: Gal Sagie [mailto:gal.sagie at gmail.com]
Sent: Wednesday, August 26, 2015 8:15 PM
To: Russell Bryant
Cc: Chandran, Sugesh; Ben Pfaff; dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace tunneling support in OVN-Openstack integration.
I agree this should move to the OpenStack mailing list as this related to it.
I agree with Ben and Russell here and don't think any of this needs to be in OVN,
I am not that familiar with that effort, but there is an effort in Nova to provide generic VIF binding
library (https://github.com/jaypipes/os_vif) and ways to let Nova run a specific code for
different binding processes.
And keep in mind that OVN right now is not an ML2 driver, it switched to be a core plugin.
I also think this relates to Nova configuration, but lets continue this in the OpenStack mailing list
On Wed, Aug 26, 2015 at 10:03 PM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:
On 08/26/2015 11:04 AM, Chandran, Sugesh wrote:
> HI Russel,
> Please find the work flow as below.
> 1. A user requests nova to boot a vm
> 2. Nova schedules the vm based on the flavor and image properties to a host
> 3. Nova asks neutron to bind the neutron port basing the selected host name and some limited information in binding profile.
> 4. The neutron network driver(ML2/OVN driver) that manages the selected node will then bind the port and select the vif type to use.
> 5. Nova reads the vif type selected by neutron and generates the Libvirt xml accordingly and boots the vm.
> a. For the normal interface nova plug the vhost-net interface to the OVS.
> b. In the dpdk case during the boot process nova plug the vhost user interface into ovs
> The VIF type(kernel vhosts/vhost-user/sriov) must be decided at step
> 4 based on the capabilities of specific compute node to allow nova to
> generate the correct Libvirt xml. Nova doesn’t know the capabilities
> of selected compute node to decide what VIF type to be used in the
> libvirt XML. It’s responsibility of Neutron to provide this
> information because Nova is not supposed to have any logic for
> manage the network. Neutron can talk only to the OVN NorthDB and this
> patch series will expose the relevant compute node details all the
> way up-to Northbound_DB. So Neutron can then instruct Nova to boot VM
> with right VIF type using the exposed information in the Northbound
> Since OVN is taking care of entire cloud network management, we feel
> that its responsibility of OVN to provide enough information to
> Nova->Hypervisor for booting the VM with right parameter set.
Are you on the openstack-dev mailing list? We should probably move the
conversation over there at this point. I can post something there. I
realize all of this isn't specific to using dpdk, but this interaction
seems more complicated than necessary. I'd like to see if we can
simplify it, instead.
dev mailing list
dev at openvswitch.org<mailto:dev at openvswitch.org>
Best Regards ,
More information about the dev