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 :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
