Hi,
During today's meeting, it was decided that we would re-purpose
Robert's
https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov to
take care of adding a Base class to take care of common processing for
SR-IOV ports.
This class would:
1. Inherits from AgentMechanismDriverBase.
2. Implements bind_port() where the binding:profile would be checked to
see if the port's vnic_type is VNIC_DIRECT or VNIC_MACVTAP.
3. Also checks to see that port belongs to vendor/product that supports
SR-IOV.
4. This class could be used by MDs that may or may not have a valid L2
agent.
5. Implement validate_port_binding(). This will always return True for Mds
that do not have an L2 agent.
Please let me know if I left out anything.
Thanks,
Sandhya
On 2/25/14 9:18 AM, "Sandhya Dasu (sadasu)" <sad...@cisco.com> wrote:
>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-por
>>>>t
>>>>-
>>>>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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
