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. Regards _Sugesh From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Wednesday, August 26, 2015 8:15 PM To: Russell Bryant Cc: Chandran, Sugesh; Ben Pfaff; dev@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 <rbry...@redhat.com<mailto:rbry...@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 > DB. > > 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. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org<mailto:dev@openvswitch.org> http://openvswitch.org/mailman/listinfo/dev -- Best Regards , The G. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
