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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list