Open Stack

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|