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?
-- 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?
-- 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.
Thanks,
Robert
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
