Re: [libvirt] [PATCH 0/7] Add support for setting QoS
-----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(a)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
But I agree, using ifb would be much more beautiful, because we
could
actually shape incoming traffic instead of dropping.
Michal