On Tue, Nov 29, 2011 at 03:46:13PM +0000, Shradha Shah wrote: > Interface Pools and Passthrough mode: > > Current Method: > The passthrough mode uses a macvtap a direct connection to connect each guest to the network. The physical interface to be used is picked from among those listed in <interface> sub elements of the <forward> element. > > The current specification for <forward> extends to allow 0 or more <interface> sub-elements: > Example: > <forward mode='passthrough' dev='eth10'/> > <interface dev='eth10'/> > <interface dev='eth12'/> > <interface dev='eth18'/> > <interface dev='eth20'/> > </forward> > > However with an ethernet card with 64 VF's or more, the above method gets tedious on the system. > > On the other hand, just parameterizing a string (eth%d) is inadequate, eg, when there are multiple non-contiguous ranges. > > Proposed Method: > The 5 patches provided along with this introductory e-mail > > i) Introduce a structure to store the state of all the virtual functions attached to each physical function > ii) Find a free virtual function given the physical function. > > The forward specification will hence only mention the physical function as the interface sub element: > Example: > <forward mode='passthrough' dev='eth2'/> > <interface dev='eth2'/> > </forward> I can see what you mean about it being tedious to construct the config with all 64 (or more) VF's listed, but this proposed change has a couple of issues First of all, the change you describe would be a semantic change in the network XML, which would break compatibility with previous releases of libvirt. Since we consider XML to be poart of our long term ABI stability guarantee I don't think we can do the change. Ignoring the ABI issue, I'm concerned that as we get PFs with an increasingly large number of VFs, we may well *not* want to associate all VFs with a single virtual network definition. eg, we might wna to put 32 VFs in one network and 32 VFs in another network. Or if we have 2 PFs, we might want to interleave VFs from several PFs across virtual networks. If all we can do is list the PF in the XML, we loose significant flexibility in how VFs are assigned. Regards, 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list