[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 27.06.2011 19:37, Christian Benvenuti (benve) wrote:
>> -----Original Message-----
>> From: Michal Privoznik [mailto:mprivozn redhat com]
>> Sent: Monday, June 27, 2011 8:34 AM
>> To: Christian Benvenuti (benve)
>> Cc: Laine Stump; libvir-list 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]