Open Stack

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-port-
>>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
>> 
>