Hi All,

Any update on this proposal for adding a new bridge called "br-phy" for 
DPDK-User space datapath support in OVN??.
Please let me know your thoughts on this.

Regards
_Sugesh

-----Original Message-----
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Chandran, Sugesh
Sent: Thursday, August 27, 2015 5:57 PM
To: Gal Sagie; Russell Bryant
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace 
tunneling support in OVN-Openstack integration.

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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to