Open Stack

On 05/07/2013 17:02, Daniel P. Berrange wrote:
> On Thu, Jul 04, 2013 at 11:53:45AM +0300, Itzik Brown wrote:
>> Hi,
>>
>> We released a code for a VIF Driver that will work with Mellanox
>> Quantum Plugin.
>> Mellanox plugin provisions Virtual Networks via embedded HCA
>> switching functionality (SR-IOV capability of Network adapter).
>>
>> The code is here:
>> https://review.openstack.org/#/c/35189/
>>
>> We allocate and assign probed SR-IOV VF (Virtual Function) as a Para
>> virtualized Interface of the instance.
>>
>> We need to:
>> 1)Allocate  device of probed VF
>> 2)Give a name to the device in the XML that will allow us to supprot
>> live migration.
>>
>> We have utility for managing embedded switch that allows VF
>> assignment and configuration.
>> We chose to use the vif['dev_name'] as a basis for the name of the
>> device. This allow us to use different devices on different hosts
>> when doing a migration.
>> When doing plug/unplug we are using a utility to allocate the device
>> and change it's name to the logical one.
> My concern / question on the review is about where the allocation
> of the device name is done.
>
> Currently you have it done on the Nova side, by calling out the
> the utility tools. This ties the Nova VIF code to the specific
> impl of the Mellanox driver in Neutron. This means it is not
> appropriate to use a generic vif_type=direct, but really need
> to ue a vif_type=mellanox.
>
> The other option, would be if you could do the device name
> allocation on the Neutron side, in response to the Nova API
> call to allocate a VIF port on the network. If this is possible,
> then all the Mellanox specific code would be in Neutron, and
> the Nova code would be entirely generic, meaning that use of
> a generic vif_type=direct would be acceptable.
>
> I favour the latter architectural split, since it de-couples
> Nova & Neutron to a greater extent. I'm not sure if is actually
> possible to implement it that way, since I'm not familiar with
> your Neuton plugin design. If it isn't possible, then you'll
> need to change your patch to use a vif_type=mellanox name
> instead
>
>> This is basically it.
>> It's a temporary solution until there will be a solution that will
>> address all the issues regarding SR-IOV.
>> Boris Pavlovic is doing work regarding SR-IOV and we plan to
>> help/adopt this effort.
>> We want to ask for your opinion regarding the way we chose.
>
> Daniel
Daniel,

Thanks for your comments.
We'll go with vif_type=mlnx_direct for now since it's easier to 
implement for now.

In the Medium/Long term we want to use interface type='network ( as 
started in https://review.openstack.org/#/c/29048/).
We have some issues we need to address with this solution:

1)How the creation of the network pool is done.
2)The scheduler should be aware of the number of available devices for 
each network pool.
3)For configuration of things like VLAN there is a need to know which 
device is allocated to each vNIC , preferably before the instance is 
started.

Itzik