[openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports
Irena Berezovsky
irenab at mellanox.com
Wed Mar 5 16:22:23 UTC 2014
Hi Robert,
I think what you mentioned can be achieved by calling into specific MD method from
SriovAgentMechanismDriverBase .try_to_bind_segment_for_agent mehod, maybe something like 'get_vif_details' before it calls to context.set_binding.
Would you mind to continue discussion over patch gerrit review https://review.openstack.org/#/c/74464/ ?
I think it will be easier to follow up the comments and decisions.
Thanks,
Irena
-----Original Message-----
From: Robert Li (baoli) [mailto:baoli at cisco.com]
Sent: Wednesday, March 05, 2014 6:10 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage questions); Sandhya Dasu (sadasu); Robert Kukura; Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports
Hi Irena,
The main reason for me to do it that way is how vif_details should be setup in our case. Do you need vlan in vif_details? The behavior in the existing base classes is that the vif_details is set during the driver init time. In our case, it needs to be setup during bind_port().
thanks,
Robert
On 3/5/14 7:37 AM, "Irena Berezovsky" <irenab at mellanox.com> wrote:
>Hi Robert, Sandhya,
>I have pushed the reference implementation
>SriovAgentMechanismDriverBase as part the following WIP:
>https://review.openstack.org/#/c/74464/
>>The code is in mech_agent.py, and very simple code for
>mech_sriov_nic_switch.py.
>>Please take a look and review.
>>BR,
>Irena
>>-----Original Message-----
>From: Irena Berezovsky [mailto:irenab at mellanox.com]
>Sent: Wednesday, March 05, 2014 9:04 AM
>To: Robert Li (baoli); Sandhya Dasu (sadasu); OpenStack Development
>Mailing List (not for usage questions); Robert Kukura; Brian Bowen
>(brbowen)
>Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
>binding of ports
>>Hi Robert,
>Seems to me that many code lines are duplicated following your proposal.
>For agent based MDs, I would prefer to inherit from
>SimpleAgentMechanismDriverBase and add there verify method for
>supported_pci_vendor_info. Specific MD will pass the list of supported
>pci_vendor_info list. The 'try_to_bind_segment_for_agent' method will
>call 'supported_pci_vendor_info', and if supported continue with
>binding flow.
>Maybe instead of a decorator method, it should be just an utility method?
>I think that the check for supported vnic_type and pci_vendor info
>support, should be done in order to see if MD should bind the port. If
>the answer is Yes, no more checks are required.
>>Coming back to the question I asked earlier, for non-agent MD, how
>would you deal with updates after port is bound, like 'admin_state_up' changes?
>I'll try to push some reference code later today.
>>BR,
>Irena
>>-----Original Message-----
>From: Robert Li (baoli) [mailto:baoli at cisco.com]
>Sent: Wednesday, March 05, 2014 4:46 AM
>To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for
>usage questions); Irena Berezovsky; Robert Kukura; Brian Bowen
>(brbowen)
>Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
>binding of ports
>>Hi Sandhya,
>>I agree with you except that I think that the class should inherit from
>MechanismDriver. I took a crack at it, and here is what I got:
>># Copyright (c) 2014 OpenStack Foundation # All Rights Reserved.
>#
># Licensed under the Apache License, Version 2.0 (the "License"); you
>may
># not use this file except in compliance with the License. You may
>obtain
># a copy of the License at
>#
># http://www.apache.org/licenses/LICENSE-2.0
>#
># Unless required by applicable law or agreed to in writing, software
># distributed under the License is distributed on an "AS IS" BASIS,
>WITHOUT
># WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
>the
># License for the specific language governing permissions and
>limitations
># under the License.
>>from abc import ABCMeta, abstractmethod
>>import functools
>import six
>>from neutron.extensions import portbindings from
>neutron.openstack.common import log from neutron.plugins.ml2 import
>driver_api as api
>>LOG = log.getLogger(__name__)
>>>DEFAULT_VNIC_TYPES_SUPPORTED = [portbindings.VNIC_DIRECT,
> portbindings.VNIC_MACVTAP]
>>def check_vnic_type_and_vendor_info(f):
> @functools.wraps(f)
> def wrapper(self, context):
> vnic_type = context.current.get(portbindings.VNIC_TYPE,
> portbindings.VNIC_NORMAL)
> if vnic_type not in self.supported_vnic_types:
> LOG.debug(_("%(func_name)s: skipped due to unsupported "
> "vnic_type: %(vnic_type)s"),
> {'func_name': f.func_name, 'vnic_type': vnic_type})
> return
>> if self.supported_pci_vendor_info:
> profile = context.current.get(portbindings.PROFILE, {})
> if not profile:
> LOG.debug(_("%s: Missing profile in port binding"),
> f.func_name)
> return
> pci_vendor_info = profile.get('pci_vendor_info')
> if not pci_vendor_info:
> LOG.debug(_("%s: Missing pci vendor info in profile"),
> f.func_name)
> return
> if pci_vendor_info not in self.supported_pci_vendor_info:
> LOG.debug(_("%(func_name)s: unsupported pci vendor "
> "info: %(info)s"),
> {'func_name': f.func_name, 'info':
>pci_vendor_info})
> return
> f(self, context)
> return wrapper
>>@six.add_metaclass(ABCMeta)
>class SriovMechanismDriverBase(api.MechanismDriver):
> """Base class for drivers that supports SR-IOV
>> The SriovMechanismDriverBase provides common code for mechanism
> drivers that supports SR-IOV. Such a driver may or may not require
> an agent to be running on the port's host.
>> MechanismDrivers that uses this base class and requires an agent must
> pass the agent type to __init__(), and must implement
> try_to_bind_segment_for_agent() and check_segment_for_agent().
>> MechanismDrivers that uses this base class may provide supported
>vendor
> information, and must provide the supported vnic types.
> """
> def __init__(self, agent_type=None, supported_pci_vendor_info=[],
> supported_vnic_types=DEFAULT_VNIC_TYPES_SUPPORTED):
> """Initialize base class for SR-IOV capable Mechanism Drivers
>> :param agent_type: Constant identifying agent type in agents_db
> :param supported_pci_vendor_info: a list of "vendor_id:product_id"
> :param supported_vnic_types: The binding:vnic_type values we
>can bind
> """
> self.supported_pci_vendor_info = supported_pci_vendor_info
> self.agent_type = agent_type
> self.supported_vnic_types = supported_vnic_types
>> def initialize(self):
> pass
>> @check_vnic_type_and_vendor_info
> def bind_port(self, context):
> LOG.debug(_("Attempting to bind port %(port)s on "
> "network %(network)s"),
> {'port': context.current['id'],
> 'network': context.network.current['id']})
>> if self.agent_type:
> for agent in context.host_agents(self.agent_type):
> LOG.debug(_("Checking agent: %s"), agent)
> if agent['alive']:
> for segment in context.network.network_segments:
> if self.try_to_bind_segment_for_agent(context,
>segment,
> agent):
> LOG.debug(_("Bound using segment: %s"),
>segment)
> return
> else:
> LOG.warning(_("Attempting to bind with dead agent:
>%s"),
> agent)
> else:
> for segment in context.network.network_segments:
> if self.try_to_bind_segment(context, segment):
> LOG.debug(_("Bound using segment: %s"), segment)
> return
>> def validate_port_binding(self, context):
> LOG.debug(_("Validating binding for port %(port)s on "
> "network %(network)s"),
> {'port': context.current['id'],
> 'network': context.network.current['id']})
> if self.agent_type:
> for agent in context.host_agents(self.agent_type):
> LOG.debug(_("Checking agent: %s"), agent)
> if agent['alive'] and self.check_segment_for_agent(
> context.bound_segment, agent):
> LOG.debug(_("Binding valid"))
> return True
> LOG.warning(_("Binding invalid for port: %s"),
>context.current)
> return False
> else:
> return True
>> @check_vnic_type_and_vendor_info
> def unbind_port(self, context):
> LOG.debug(_("Unbinding port %(port)s on "
> "network %(network)s"),
> {'port': context.current['id'],
> 'network': context.network.current['id']})
>> @abstractmethod
> def try_to_bind_segment_for_agent(self, context, segment, agent):
> """Try to bind with segment for agent.
>> :param context: PortContext instance describing the port
> :param segment: segment dictionary describing segment to bind
> :param agent: agents_db entry describing agent to bind
> :returns: True iff segment has been bound for agent
>> Called inside transaction during bind_port() so that derived
> MechanismDrivers can use agent_db data along with built-in
> knowledge of the corresponding agent's capabilities to attempt
> to bind to the specified network segment for the agent.
>> If the segment can be bound for the agent, this function must
> call context.set_binding() with appropriate values and then
> return True. Otherwise, it must return False.
> """
>> @abstractmethod
> def check_segment_for_agent(self, segment, agent):
> """Check if segment can be bound for agent.
>> :param segment: segment dictionary describing segment to bind
> :param agent: agents_db entry describing agent to bind
> :returns: True iff segment can be bound for agent
>> Called inside transaction during validate_port_binding() so
> that derived MechanismDrivers can use agent_db data along with
> built-in knowledge of the corresponding agent's capabilities
> to determine whether or not the specified network segment can
> be bound for the agent.
> """
>> @abstractmethod
> def try_to_bind_segment(self, segment):
> """Check if segment can be bound.
>> :param segment: segment dictionary describing segment to bind
> :returns: True iff segment can be bound
>> Called inside transaction during bind_port() so that derived
> MechanismDrivers can use database data along with built-in
> knowledge to attempt to bind to the specified network segment
>> If the segment can be bound, this function must
> call context.set_binding() with appropriate values and then
> return True. Otherwise, it must return False.
> """
>>>>A SRIOV MD would inherit from it and implement
>try_to_bind_segment_for_agent() and check_segment_for_agent() and
>try_to_bind_segment(). If an agent is required, the first two methods
>should have concrete implementation, and the third may only contain
>'pass'. Otherwise, the first two are 'pass', and the third needs to be
>implemented.
>>In the inherited class, its __init__ method should set the supported
>pci_vendor_info by either hard coding or by configuration (which is
>preferred so that code doesn't need to be changed with newly supported
>cards).
>in the bind segment method, vif_type and vif_details should be set, and
>set_binding() called.
>>methods inherited from MechanismDriver, such as
>create_port_precommit()/postcommit(),
>update_port_precommit()/postcommit
>can be decorated with check_vnic_type_and_vendor_info so that they
>won't be called if vnic_type and vendor_info don't match.
>>Let me know what you think.
>>thanks,
>Robert
>>>>>On 3/4/14 4:08 PM, "Sandhya Dasu (sadasu)" <sadasu at cisco.com> wrote:
>>>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)" <sadasu at 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)" <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-extr
>>>>>>a
>>>>>>-po
>>>>>>r
>>>>>>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 <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-t
>>>>>> y
>>>>>> pe
>>>>>> 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
>>>>>>>>>_______________________________________________
>>>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
More information about the OpenStack-dev
mailing list