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

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


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