Open Stack

+1

It's totally different between ovs and userspace ovs.
also, there is strong need to keep ovs even we have a userspace ovs in the
same host


On Fri, Jul 11, 2014 at 7:59 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> On 10 July 2014 08:19, Czesnowicz, Przemyslaw <
> przemyslaw.czesnowicz at intel.com> wrote:
>
>>  Hi,
>>
>>
>>
>> Thanks for Your answers.
>>
>>
>>
>> Yep using binding:vif_details makes more sense. We would like to reuse
>> VIF_TYPE_OVS and modify the nova to use the userspace vhost when ‘use_dpdk’
>> flag is present.
>>
>
> I admit it's a bit of a pedantic point, but connecting to OVS and
> connecting to userspace OVS would seem to be drastically different (neither
> type will work with the wrong switch) so using a different binding type
> would seem to be rather more appropriate than if(this flag is set) { do
> something completely different; }.
>
>
>>  What we are missing is how to inform the ml2 plugin/mechanism drivers
>> when to put that ‘use_dpdk’ flag into vif_details.
>>
>
> You might want to refer to the mail I sent yesterday evening about getting
> Nova to tell Neutron what binding types it supports.  I'm not sure it's the
> answer to your problem but it might well simplify it.
>
>  On the node ovs_neutron_agent could look up datapath_type in ovsdb, but
>> how can we provide that info to the plugin?
>>
>> Currently there is no mechanism to get node specific info into the ml2
>> plugin (or at least we don’t see any).
>>
>>
>>
>> Any ideas on how this could be implemented?
>>
>>
>>
>> Regards
>>
>> Przemek
>>
>> *From:* Irena Berezovsky [mailto:irenab at mellanox.com
>> <irenab at mellanox.com>]
>> *Sent:* Thursday, July 10, 2014 8:08 AM
>> *To:* OpenStack Development Mailing List (not for usage questions);
>> Czesnowicz, Przemyslaw
>> *Cc:* Mooney, Sean K
>> *Subject:* RE: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2
>> plugin
>>
>>
>>
>> Hi,
>>
>> For passing  information from neutron to nova VIF Driver, you should use
>> binding:vif_details dictionary.  You may not require new VIF_TYPE, but can
>> leverage the existing VIF_TYPE_OVS, and add ‘use_dpdk’   in vif_details
>> dictionary. This will require some rework of the existing libvirt
>> vif_driver VIF_TYPE_OVS.
>>
>>
>>
>> Binding:profile is considered as input dictionary that is used to pass
>> information required for port binding on Server side. You  may use
>> binding:profile to pass in  a dpdk ovs request, so it will be taken into
>> port binding consideration by ML2 plugin.
>>
>>
>>
>> I am not sure regarding new vnic_type, since it will require  port owner
>> to pass in the requested type. Is it your intention? Should the port owner
>> be aware of dpdk ovs usage?
>>
>> There is also VM scheduling consideration that if certain vnic_type is
>> requested, VM should be scheduled on the node that can satisfy the request.
>>
>>
>>
>> Regards,
>>
>> Irena
>>
>>
>>
>>
>>
>> *From:* loy wolfe [mailto:loywolfe at gmail.com <loywolfe at gmail.com>]
>> *Sent:* Thursday, July 10, 2014 6:00 AM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Cc:* Mooney, Sean K
>> *Subject:* Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2
>> plugin
>>
>>
>>
>> i think both a new vnic_type and a new vif_type should be added. now vnic
>> has three types: normal, direct, macvtap, then we need a new type of
>> "uservhost".
>>
>>
>>
>> as for vif_type, now we have VIF_TYPE_OVS, VIF_TYPE_QBH/QBG, VIF_HW_VEB,
>> so we need a new VIF_TYPE_USEROVS
>>
>>
>>
>> I don't think it's a good idea to directly reuse ovs agent, for we have
>> to consider use cases that ovs and userovs co-exists. Now it's a little
>> painful to fork and write a new agent, but it will be easier when ML2 agent
>> BP is merged in the future. (
>> https://etherpad.openstack.org/p/modular-l2-agent-outline)
>>
>>
>>
>> On Wed, Jul 9, 2014 at 11:08 PM, Czesnowicz, Przemyslaw <
>> przemyslaw.czesnowicz at intel.com> wrote:
>>
>> Hi
>>
>>
>>
>> We (Intel Openstack team) would like to add support for dpdk based
>> userspace openvswitch using mech_openvswitch and mech_odl from ML2 plugin.
>>
>> The dpdk enabled ovs comes in two flavours one is netdev incorporated
>> into vanilla ovs the other is a fork of ovs with a dpdk datapath (
>> https://github.com/01org/dpdk-ovs ).
>>
>> Both flavours use userspace vhost mechanism to connect the VMs to the
>> switch.
>>
>>
>>
>> Our initial approach was to extend ovs vif bindings in nova and add a
>> config parameter to specify when userspace vhost should be used.
>>
>> Spec : https://review.openstack.org/95805
>>
>> Code: https://review.openstack.org/100256
>>
>>
>>
>> Nova devs rejected this approach saying that Neutron should pass all
>> necessary information to nova to select vif bindings.
>>
>>
>>
>> Currently we are looking for a way to pass information from Neutron to
>> Nova that dpdk enabled ovs is being used while still being able to use
>> mech_openvswitch and ovs_neutron_agent or mech_odl.
>>
>>
>>
>>
>> We thought of two possible solutions:
>>
>> 1.      Use binding_profile to provide node specific info to nova.
>>
>> Agent rpc api would be extended to allow agents to send node profile to
>> neutron plugin.
>>
>> That info would be stored in db and passed to nova when binding on this
>> specific host is requested.
>>
>> This could be used to support our use case or pass other info to nova
>> (i.e name of integration bridge)
>>
>>
>>
>> 2.      Let mech_openvswitch and mech_odl detect what binding type to
>> use.
>>
>> When asked for port binding mech_openvswitch and mech_odl would call the
>> agent or odl  to check what bindings to use (VIF_TYPE_OVS or
>> VIF_TYPE_DPDKVHOST)
>>
>>
>>
>> So, what would be the best way to support our usecase, is it one of the
>> above ?
>>
>>
>>
>> Best regards
>>
>> Przemek
>>
>> --------------------------------------------------------------
>> Intel Shannon Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>> Registered Number: 308263
>> Business address: Dromore House, East Park, Shannon, Co. Clare
>>
>> This e-mail and any attachments may contain confidential material for the
>> sole use of the intended recipient(s). Any review or distribution by others
>> is strictly prohibited. If you are not the intended recipient, please
>> contact the sender and delete all copies.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --------------------------------------------------------------
>> Intel Shannon Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>> Registered Number: 308263
>> Business address: Dromore House, East Park, Shannon, Co. Clare
>>
>> This e-mail and any attachments may contain confidential material for the
>> sole use of the intended recipient(s). Any review or distribution by others
>> is strictly prohibited. If you are not the intended recipient, please
>> contact the sender and delete all copies.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140711/aaee723d/attachment.html>