[openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

Sandhya Dasu (sadasu) sadasu at cisco.com
Wed Mar 5 14:47:30 UTC 2014


Hi Irena,
    My MD has to take care of admin state changes since I have no L2
agent. I think that is what Bob also alluded to. That being said, I am not
doing anything specific to handle admin_state_up/down. The SR-IOV port on
my device is always going to be up, for now atleast.

Thanks,
Sandhya

On 3/5/14 1:56 AM, "Irena Berezovsky" <irenab at mellanox.com> wrote:

>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-extra
>>>>>>-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-ty
>>>>>> 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
>>
>




More information about the OpenStack-dev mailing list