On 12/05/2011 11:37 AM, Daniel P. Berrange wrote: > On Tue, Nov 29, 2011 at 08:29:35PM -0500, Laine Stump wrote: >> On 11/29/2011 02:53 PM, Daniel P. Berrange wrote: >>> 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. >> >>> 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. >> >> My first concern too when I saw the patch was the semantic change >> (but also the loss of flexibility), which is obviously a no-go. It's >> a convenient capability to have though, so it would be nice to get >> it in somehow. What if we allowed including all the VFs associated >> with a PF by adding an extra attribute? e.g.: >> >> <interface dev='eth10' type='sriov'/> > > This feels a little bit wrong to me. > >> (or whatever is more appropriate in place of "sriov"). Or possibly a >> different element type could be used: >> >> <pf dev='eth10'/> > > I like this idea, because it is providing additional useful info, > rather than changing existing elements, so it is maximally > compatible. > >> (didn't want to spend time thinking of a better name than "pf"...). >> >> At the time the network is created, this would cause libvirt to get >> the list of all VFs for the given PF and put them into the pool. >> This could be used instead of, or in combination with, the existing >> <interface dev='eth1'/> form. Thus the existing semantics would be >> preserved, the flexibility of specifying individual devices would be >> retained, and the desired convenience of adding all VFs of a PF with >> a single line would be added. > > IIUC, what you're suggesting is the following behaviour: > > * Explicit interface list. App inputs: > > <forward mode='passthrough'> > <interface dev='eth10'/> > <interface dev='eth11'/> > <interface dev='eth12'/> > <interface dev='eth13'/> > </forward> > > libvirt does not change XML > > * Automatically interface list from PF. App inputs: > > <forward mode='passthrough'> > <pf dev='eth0'/> > </forward> > > libvirt expands XML to be > > <forward mode='passthrough'> > <pf dev='eth0'/> > <interface dev='eth10'/> > <interface dev='eth11'/> > <interface dev='eth12'/> > <interface dev='eth13'/> > </forward> > > This is good because all previous info is still intact > > Regards, > Daniel Daniel and Laine, I agree with the above mentioned suggestion and I will re-submit a set of patches using your suggestions. Many thanks for your input. Regards, Shradha -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list