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)" <sad...@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" <ire...@mellanox.com> wrote:
>
>>Please see inline my understanding
>>
>>-----Original Message-----
>>From: Robert Kukura [mailto:rkuk...@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 <sad...@cisco.com <mailto:sad...@cisco.com>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> <openstack-dev@lists.openstack.org
>>> <mailto:openstack-dev@lists.openstack.org>>
>>> Date: Monday, February 3, 2014 3:14 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev@lists.openstack.org
>>> <mailto:openstack-dev@lists.openstack.org>>, Irena Berezovsky
>>> <ire...@mellanox.com <mailto:ire...@mellanox.com>>, "Robert Li (baoli)"
>>> <ba...@cisco.com <mailto:ba...@cisco.com>>, Robert Kukura
>>> <rkuk...@redhat.com <mailto:rkuk...@redhat.com>>, "Brian Bowen
>>> (brbowen)" <brbo...@cisco.com <mailto:brbo...@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 <sad...@cisco.com <mailto:sad...@cisco.com>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> <openstack-dev@lists.openstack.org
>>> <mailto:openstack-dev@lists.openstack.org>>
>>> Date: Monday, February 3, 2014 1:26 PM
>>> To: Irena Berezovsky <ire...@mellanox.com
>>> <mailto:ire...@mellanox.com>>, "Robert Li (baoli)" <ba...@cisco.com
>>> <mailto:ba...@cisco.com>>, Robert Kukura <rkuk...@redhat.com
>>> <mailto:rkuk...@redhat.com>>, "OpenStack Development Mailing List (not
>>>for usage questions)"
>>> <openstack-dev@lists.openstack.org
>>> <mailto:openstack-dev@lists.openstack.org>>, "Brian Bowen (brbowen)"
>>> <brbo...@cisco.com <mailto:brbo...@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 <ire...@mellanox.com
>>> <mailto:ire...@mellanox.com>>
>>> Date: Monday, February 3, 2014 12:52 AM
>>> To: Sandhya Dasu <sad...@cisco.com <mailto:sad...@cisco.com>>, "Robert
>>> Li (baoli)" <ba...@cisco.com <mailto:ba...@cisco.com>>, Robert Kukura
>>> <rkuk...@redhat.com <mailto:rkuk...@redhat.com>>, "OpenStack
>>> Development Mailing List (not for usage questions)"
>>> <openstack-dev@lists.openstack.org
>>> <mailto:openstack-dev@lists.openstack.org>>, "Brian Bowen (brbowen)"
>>> <brbo...@cisco.com <mailto:brbo...@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:sad...@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 <ire...@mellanox.com
>>> <mailto:ire...@mellanox.com>>
>>> *Date: *Thursday, January 30, 2014 4:13 PM
>>> *To: *"Robert Li (baoli)" <ba...@cisco.com <mailto:ba...@cisco.com>>,
>>> Robert Kukura <rkuk...@redhat.com <mailto:rkuk...@redhat.com>>,
>>> Sandhya Dasu <sad...@cisco.com <mailto:sad...@cisco.com>>, "OpenStack
>>> Development Mailing List (not for usage questions)"
>>> <openstack-dev@lists.openstack.org
>>> <mailto:openstack-dev@lists.openstack.org>>, "Brian Bowen (brbowen)"
>>> <brbo...@cisco.com <mailto:brbo...@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:ba...@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@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to