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:ba...@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" <ire...@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:ire...@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:ba...@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)" <sad...@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)" <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-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 <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-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@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


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

Reply via email to