Open Stack

Hi Irena,

Thanks for the Reply. See inline…

If possible, can we put details on what would be exactly covered by each BP?

--Robert

On 1/30/14 4:13 PM, "Irena Berezovsky" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:

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

[Robert] This makes sense to me. Would this live in the extension area, or would it be in the ML2 area? I thought one of the above listed would cover the persistence of SRIOV attributes. But sounds like we need this BP.

  -- 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.

[Robert] Sounds good to me. But again, which BP would cover this?

 -- 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.
[Robert] I get the idea. it relies on what are plugged onto the integration bridge by nova to determine if it needs to take actions.


Thanks,
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140131/d9b294ca/attachment.html>