Open Stack

On 01/31/2014 11:45 AM, Sandhya Dasu (sadasu) wrote:
> 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.

That BP covers including additional information from the bound network
segment's TypeDriver in the response to the get_device_details RPC. I
believe the bound MechanismDriver should also have the opportunity to
include additional information in that response. Possibly the bound
MechanismDriver is what would decide what information from the bound
segment's TypeDriver is needed by the L2 agent it supports. Anyway, I'm
still hopeful we can get this sorted out and implemented in icehouse,
but I agree its best to not depend on it until juno.

> 
> Introducing, SRIOVPortProfileMixin would be creating yet another way to
> take care of extra port config. Let me know what you think.

This SRIOVPortProfileMixin has been mentioned a few times now. I'm not
clear on what this class is intended to be mixed into. Is this something
that would be mixed into any plugin that supports SRIOV?

If so, I'd prefer not to use such a mixin class in ML2, where we've so
far been avoiding the need to add any specific support for SRIOV to the
plugin itself. Instead we've been trying to define generic features in
ML2 that allow SRIOV to be packaged as an optional feature enabled by
configuring a MechanismDriver that supports it. This approach is a prime
example of the "modular" goal of "Modular Layer 2".

-Bob

> 
> 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-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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>