[openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports
Irena Berezovsky
irenab at mellanox.com
Wed Feb 26 05:53:08 UTC 2014
Hi Sandhya,
I mentioned the port state with regards to expected operation that can be applied to neutron port after neutron port is already bound to certain virtual interface.
Since for my case, there will be neutron L2 agent on Host, it will manage port admin state locally. I am not sure how it should work for your case, and if you need L2 agent for this.
BR,
Irena
-----Original Message-----
From: Sandhya Dasu (sadasu) [mailto:sadasu at cisco.com]
Sent: Tuesday, February 25, 2014 4:19 PM
To: OpenStack Development Mailing List (not for usage questions); Irena Berezovsky; Robert Kukura; Robert Li (baoli); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports
Hi,
As a follow up from today's IRC, Irena, are you looking to write the below mentioned Base/Mixin class that inherits from AgentMechanismDriverBase class? When you mentioned port state, were you referring to the validate_port_binding() method?
Pls clarify.
Thanks,
Sandhya
On 2/6/14 7:57 AM, "Sandhya Dasu (sadasu)" <sadasu at cisco.com> wrote:
>Hi Bob and Irena,
> Thanks for the clarification. Irena, I am not opposed to a
>SriovMechanismDriverBase/Mixin approach, but I want to first figure out
>how much common functionality there is. Have you already looked at this?
>
>Thanks,
>Sandhya
>
>On 2/5/14 1:58 AM, "Irena Berezovsky" <irenab at mellanox.com> wrote:
>
>>Please see inline my understanding
>>
>>-----Original Message-----
>>From: Robert Kukura [mailto:rkukura at redhat.com]
>>Sent: Tuesday, February 04, 2014 11:57 PM
>>To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for
>>usage questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen
>>(brbowen)
>>Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
>>binding of ports
>>
>>On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote:
>>> Hi,
>>> I have a couple of questions for ML2 experts regarding support
>>> of SR-IOV ports.
>>
>>I'll try, but I think these questions might be more about how the
>>various SR-IOV implementations will work than about ML2 itself...
>>
>>> 1. The SR-IOV ports would not be managed by ova or linuxbridge L2
>>> agents. So, how does a MD for SR-IOV ports bind/unbind its ports to
>>> the host? Will it just be a db update?
>>
>>I think whether or not to use an L2 agent depends on the specific
>>SR-IOV implementation. Some (Mellanox?) might use an L2 agent, while
>>others
>>(Cisco?) might put information in binding:vif_details that lets the
>>nova VIF driver take care of setting up the port without an L2 agent.
>>[IrenaB] Based on VIF_Type that MD defines, and going forward with
>>other binding:vif_details attributes, VIFDriver should do the VIF pluging part.
>>As for required networking configuration is required, it is usually
>>done either by L2 Agent or external Controller, depends on MD.
>>
>>>
>>> 2. Also, how do we handle the functionality in mech_agent.py, within
>>> the SR-IOV context?
>>
>>My guess is that those SR-IOV MechanismDrivers that use an L2 agent
>>would inherit the AgentMechanismDriverBase class if it provides useful
>>functionality, but any MechanismDriver implementation is free to not
>>use this base class if its not applicable. I'm not sure if an
>>SriovMechanismDriverBase (or SriovMechanismDriverMixin) class is being
>>planned, and how that would relate to AgentMechanismDriverBase.
>>
>>[IrenaB] Agree with Bob, and as I stated before I think there is a
>>need for SriovMechanismDriverBase/Mixin that provides all the generic
>>functionality and helper methods that are common to SRIOV ports.
>>-Bob
>>
>>>
>>> Thanks,
>>> Sandhya
>>>
>>> From: Sandhya Dasu <sadasu at cisco.com <mailto:sadasu at cisco.com>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Date: Monday, February 3, 2014 3:14 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>, Irena Berezovsky
>>><irenab at mellanox.com <mailto:irenab at mellanox.com>>, "Robert Li (baoli)"
>>> <baoli at cisco.com <mailto:baoli at cisco.com>>, Robert Kukura
>>><rkukura at redhat.com <mailto:rkukura at redhat.com>>, "Brian Bowen
>>>(brbowen)" <brbowen at cisco.com <mailto:brbowen at cisco.com>>
>>> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
>>>extra hr of discussion today
>>>
>>> Hi,
>>> Since, openstack-meeting-alt seems to be in use, baoli and
>>> myself are moving to openstack-meeting. Hopefully, Bob Kukura &
>>> Irena can join soon.
>>>
>>> Thanks,
>>> Sandhya
>>>
>>> From: Sandhya Dasu <sadasu at cisco.com <mailto:sadasu at cisco.com>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>
>>> Date: Monday, February 3, 2014 1:26 PM
>>> To: Irena Berezovsky <irenab at mellanox.com
>>><mailto:irenab at mellanox.com>>, "Robert Li (baoli)" <baoli at cisco.com
>>><mailto:baoli at cisco.com>>, Robert Kukura <rkukura at redhat.com
>>><mailto:rkukura at redhat.com>>, "OpenStack Development Mailing List
>>>(not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>, "Brian Bowen (brbowen)"
>>> <brbowen at cisco.com <mailto:brbowen at cisco.com>>
>>> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
>>>extra hr of discussion today
>>>
>>> Hi all,
>>> Both openstack-meeting and openstack-meeting-alt are available
>>> today. Lets meet at UTC 2000 @ openstack-meeting-alt.
>>>
>>> Thanks,
>>> Sandhya
>>>
>>> From: Irena Berezovsky <irenab at mellanox.com
>>> <mailto:irenab at mellanox.com>>
>>> Date: Monday, February 3, 2014 12:52 AM
>>> To: Sandhya Dasu <sadasu at cisco.com <mailto:sadasu at cisco.com>>,
>>> "Robert Li (baoli)" <baoli at cisco.com <mailto:baoli at cisco.com>>,
>>> Robert Kukura <rkukura at redhat.com <mailto:rkukura at redhat.com>>,
>>> "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>, "Brian Bowen (brbowen)"
>>> <brbowen at cisco.com <mailto:brbowen at cisco.com>>
>>> Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
>>> on Jan. 30th
>>>
>>> Hi Sandhya,
>>>
>>> Can you please elaborate how do you suggest to extend the below bp
>>> for SRIOV Ports managed by different Mechanism Driver?
>>>
>>> I am not biased to any specific direction here, just think we need
>>> common layer for managing SRIOV port at neutron, since there is a
>>> common pass between nova and neutron.
>>>
>>>
>>>
>>> BR,
>>>
>>> Irena
>>>
>>>
>>>
>>>
>>>
>>> *From:*Sandhya Dasu (sadasu) [mailto:sadasu at cisco.com]
>>> *Sent:* Friday, January 31, 2014 6:46 PM
>>> *To:* Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack
>>> Development Mailing List (not for usage questions); Brian Bowen
>>> (brbowen)
>>> *Subject:* Re: [openstack-dev] [nova][neutron] PCI pass-through
>>> SRIOV on Jan. 30th
>>>
>>>
>>>
>>> Hi Irena,
>>>
>>> I was initially looking
>>> at
>>>
>>>https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-p
>>>ort
>>>-
>>>info to take care of the extra information required to set up the
>>>SR-IOV port.
>>> When the scope of the BP was being decided, we had very little info
>>>about our own design so I didn't give any feedback about SR-IOV ports.
>>> But, I feel that this is the direction we should be going. Maybe we
>>>should target this in Juno.
>>>
>>>
>>>
>>> Introducing, */SRIOVPortProfileMixin /*would be creating yet another
>>> way to take care of extra port config. Let me know what you think.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Sandhya
>>>
>>>
>>>
>>> *From: *Irena Berezovsky <irenab at mellanox.com
>>> <mailto:irenab at mellanox.com>>
>>> *Date: *Thursday, January 30, 2014 4:13 PM
>>> *To: *"Robert Li (baoli)" <baoli at cisco.com
>>> <mailto:baoli at cisco.com>>, Robert Kukura <rkukura at redhat.com
>>> <mailto:rkukura at redhat.com>>, Sandhya Dasu <sadasu at cisco.com
>>> <mailto:sadasu at cisco.com>>, "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org
>>> <mailto:openstack-dev at lists.openstack.org>>, "Brian Bowen (brbowen)"
>>> <brbowen at cisco.com <mailto:brbowen at cisco.com>>
>>> *Subject: *RE: [openstack-dev] [nova][neutron] PCI pass-through
>>> SRIOV on Jan. 30th
>>>
>>>
>>>
>>> Robert,
>>>
>>> Thank you very much for the summary.
>>>
>>> Please, see inline
>>>
>>>
>>>
>>> *From:*Robert Li (baoli) [mailto:baoli at cisco.com]
>>> *Sent:* Thursday, January 30, 2014 10:45 PM
>>> *To:* Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky;
>>> OpenStack Development Mailing List (not for usage questions); Brian
>>> Bowen (brbowen)
>>> *Subject:* [openstack-dev] [nova][neutron] PCI pass-through SRIOV on
>>> Jan. 30th
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> We made a lot of progress today. We agreed that:
>>>
>>> -- vnic_type will be a top level attribute as binding:vnic_type
>>>
>>> -- BPs:
>>>
>>> * Irena's
>>> https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type
>>> for binding:vnic_type
>>>
>>> * Bob to submit a BP for binding:profile in ML2. SRIOV input
>>> info will be encapsulated in binding:profile
>>>
>>> * Bob to submit a BP for binding:vif_details in ML2. SRIOV
>>> output info will be encapsulated in binding:vif_details, which may
>>> include other information like security parameters. For SRIOV,
>>> vlan_id and profileid are candidates.
>>>
>>> -- new arguments for port-create will be implicit arguments. Future
>>> release may make them explicit. New argument: --binding:vnic_type
>>> {virtio, direct, macvtap}.
>>>
>>> I think that currently we can make do without the profileid as an
>>> input parameter from the user. The mechanism driver will return a
>>> profileid in the vif output.
>>>
>>>
>>>
>>> Please correct any misstatement in above.
>>>
>>>
>>>
>>> Issues:
>>>
>>> -- do we need a common utils/driver for SRIOV generic parts to be
>>> used by individual Mechanism drivers that support SRIOV? More
>>> details on what would be included in this sriov utils/driver? I'm
>>> thinking that a candidate would be the helper functions to interpret
>>> the pci_slot, which is proposed as a string. Anything else in your mind?
>>>
>>> */[IrenaB] I thought on some SRIOVPortProfileMixin to handle and
>>> persist SRIOV port related attributes/*
>>>
>>>
>>>
>>> -- what should mechanism drivers put in binding:vif_details and
>>> how nova would use this information? as far as I see it from the
>>> code, a VIF object is created and populated based on information
>>> provided by neutron (from get network and get port)
>>>
>>>
>>>
>>> Questions:
>>>
>>> -- nova needs to work with both ML2 and non-ML2 plugins. For
>>> regular plugins, binding:vnic_type will not be set, I guess. Then
>>> would it be treated as a virtio type? And if a non-ML2 plugin wants
>>> to support SRIOV, would it need to implement vnic-type,
>>> binding:profile, binding:vif-details for SRIOV itself?
>>>
>>> */[IrenaB] vnic_type will be added as an additional attribute to
>>> binding extension. For persistency it should be added in
>>> PortBindingMixin for non ML2. I didn't think to cover it as part of
>>> ML2 vnic_type bp./*
>>>
>>> */For the rest attributes, need to see what Bob plans./*
>>>
>>>
>>>
>>> -- is a neutron agent making decision based on the binding:vif_type?
>>> In that case, it makes sense for binding:vnic_type not to be
>>> exposed to agents.
>>>
>>> */[IrenaB] vnic_type is input parameter that will eventually cause
>>> certain vif_type to be sent to GenericVIFDriver and create network
>>> interface. Neutron agents periodically scan for attached interfaces.
>>> For example, OVS agent will look only for OVS interfaces, so if
>>> SRIOV interface is created, it won't be discovered by OVS agent./*
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Robert
>>>
>>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list