Open Stack

On 01/30/2014 03:44 PM, Robert Li (baoli) wrote:
> 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

This is https://blueprints.launchpad.net/neutron/+spec/ml2-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.

This is https://blueprints.launchpad.net/neutron/+spec/vif-details.

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

By "vif output" here, do you mean binding:vif_details? If so, do we know
how the MD gets the value to return?

> 
> Please correct any misstatement in above.

Sounds right to me.

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

I'd suggest looking at the
neutron.plugins.ml2.drivers.mech_agent.AgentMechanismDriverBase class
that is inherited by the various MDs that use L2 agents. This handles
most of what the MDs need to do, and the derived classes only deal with
details specific to that L2 agent. Maybe a similar
SriovMechanismDriverBase class would make sense.

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

I think nova should include the entire binding:vif_details attribute in
its VIF object so that the GenericVIFDriver can interpret whatever
key/value pairs are needed (based on the binding:vif_type). We are going
to need to work closely with the nova team to make this so.

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

Makes sense to me.

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

I'm not sure I understand what an L2 agent would do with this. As I've
mentioned, I think ML2 will eventually allow the bound MD to add
whatever info it needs to the response returned for the
get_device_details RPC. If the vnic_type is needed in an SRIOV-specific
L2 agent, that should allow the associated driver to supply it.

> 
> Thanks,
> Robert

-Bob