[libvirt] [PATCH 0/7] Add support for setting QoS

[Michal Privoznik]

On 01.07.2011 09:20, Michal Privoznik wrote:
> On 27.06.2011 19:37, Christian Benvenuti (benve) wrote:
>>> -----Original Message-----
>>> From: Michal Privoznik [mailto:mprivozn at redhat.com]
>>> Sent: Monday, June 27, 2011 8:34 AM
>>> To: Christian Benvenuti (benve)
>>> Cc: Laine Stump; libvir-list at redhat.com
>>> Subject: Re: [libvirt] [PATCH 0/7] Add support for setting QoS
>>>
>>> On 24.06.2011 20:00, Christian Benvenuti (benve) wrote:
>>>>>> 3) Similarly for macvtap<network>s, will the network-wide
>>> bandwidth
>>>>>> limiting be applied to the physical ethernet device? This would
>>>>>> have the side effect of including host traffic on that interface
>> in
>>>>>> the bandwidth totals, but I don't see a way around it.
>>>>> With this patch as-is, shaping rules are applied only when creating
>>>> TAP
>>>>> devices. This mean only network types VIR_DOMAIN_NET_TYPE_NETWORK
>>> and
>>>>> VIR_DOMAIN_NET_TYPE_BRIDGE.
>>>>>>
>>>>>> 4) Finally on that topic, what about<network>s that have a pool
>> of
>>>>>> physical ethernets to be used macvtap-style? Is there any way we
>>> can
>>>>>> do bandwidth limiting on an aggregated collection of network
>>>> interfaces?
>>>>>> Or
>>>>>> will attempts to configure this necessarily result in a "config
>> not
>>>>>> supported" log message?
>>>>> Huh, I didn't know it is possible to have a pool of devices within
>>> one
>>>>> <network>. So in this case, this patch silently does nothing.
>>>>
>>>> The IFB (Intermediate Functional Block) allows you to
>>>> configure aggregate QoS on multiple interfaces.
>>>>
>>>> /Chris
>>>>
>>>>
>>> Yes, but we would then need to create those IFB devices on the fly
>>> (e.g.
>>> on domain startup) and I don't think there is other way than unloading
>>> and then loading the ifb module (with different parameter) which
>>> however
>>> would break other domains connections. Or am I missing something?
>>
>> Adding support for dynamic creation/deletion of IFB devices (for example
>> via netlink) should not be that hard. If that's the only reason for not
>> using it, I would consider the option of extending the IFB module.
>>
>> /Chris
>
> Sorry for mystification. Simple reading of source code for iproute2 has
> shown ifb module understand netlink interface and thus new ifb device
> can be simply created via "ip link add name<name>  type ifb".
>
> So I'll rewrite and post v2.
>
> Michal

Although, allowing to set bandwidth limits per domain as whole (and thus 
use IFB) might be considered as extension to this patch, which can be 
added later. So I'll post a v2 which will not contain IFB feature, but 
will be rebased to current HEAD. I think splitting this huge QoS feature 
in smaller parts might increase chances of getting it in.

Michal