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

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


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