On 23.06.2011 19:17, Laine Stump wrote:
On 06/23/2011 11:36 AM, Michal Privoznik wrote:
This patch series add support for setting traffic shaping and policing on both domain's interface and network's virtual bridge. Basically, this is done via 'tc' from iproute2 package. For shaping is HTB used, for policing we need u32 match selector. Both should be available in RHEL-6 kernel.
Some general questions:
1) Just to make sure I understand it, if <bandwidth> is specified in the network XML, that will be applied to the bridge itself, not to each interface on the bridge. (So, if we want to have the per-guest bandwidth specified in a single place, that will be where my proposed <portgroup> comes in - a <bandwidth> specified in a <portgroup> will be applied individually to each guest interface that is part of the portgroup.) Yes. If I want to support per-guest traffic shaping in these patches, I need to create a separate XML for that. Neither <network> nor <domain> is not the right place. So I'd end up with the same structure as you.
2) Following on (2). Once host bridges (ie, a bridge device that's directly connected to a physical NIC) are available as <network>s, can the limiting then be applied to the bridge device, or will it instead need to be applied to the ethernet device that the bridge is using to attach to the physical network? If the latter is the case, then we'll need a way to determine which device that is (currently I hadn't planned on putting that information in the XML, because it's configured outside of libvirt, and this could lead to mismatches between what libvirt XML shows and reality). Fortunately, it is the first case. Therefore is XML inserted into <interface> and <network>. Rules are applied only on desired device. Not anywhere else.
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.
5) I see you've put the data structures and parsing/formatting functions that are used by both network_conf.c and domain_conf.c in the util directory. I've been wondering myself what to do with similar structs/functions that will be used in both network and domain XML (eg, <virtualport> will soon be used by both) - does everyone agree this is the right way to handle it? Or should there be a common file in the conf directory instead? (I don't have an opinion, but want to "do the right thing" when I write my own code) Yeah, I was thinking the same way. When I wrote the code, I've decided for src/util. But I would not hesitate if somebody wants it in src/conf.
Michal