[libvirt] [PATCH 0/5] Interface pools and passthrough mode

[Daniel P. Berrange]

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
-- 
|: 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 :|