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

[Shradha Shah]

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