On Tue, Aug 08, 2017 at 03:13:36PM +0200, Alberto Garcia wrote:
On Mon 31 Jul 2017 11:54:41 AM CEST, Manos Pitsidianakis wrote:block/throttle.c uses existing I/O throttle infrastructure inside a block filter driver. I/O operations are intercepted in the filter's read/write coroutines, and referred to block/throttle-groups.cThe driver can be used with the syntax -drive driver=throttle,file.filename=foo.qcow2, \ limits.iops-total=...,throttle-group=barSorry for not having noticed this earlier, but can't you define the throttling group (and its limits) using -object throttle-group ... as shown in the previous patch, and simply reference it here? Or would we have two alternative ways of setting the throttling limits? What happens if you have many -drive lines each one with a different set of limits but with the same throttling group?
The limits of the last one to be processed will win. Quoting a reply I made to Kevin on the interface test patch:
You're right, I missed this. The test result shows that this command succeeds. Do we really want to allow other nodes to be affected with a blockdev-add? Wouldn't it be cleaner to just forbid the combination of limits and throtte-group?So basically only anonymous, immutable groups can be created through the driver then. All other shared group configurations must be explicitly created with an -object / object-add syntax. I think this is a neat separation and compromise if we allow anonymous groups. If not, we can ignore limits on the throttle driver.
So basically if we have anonymous groups, we accept limits in the driver options but only without a group-name. Without anonymous groups, we remove limits from the driver options and only use the object-add/-object commands to create throttle groups. Does this sound like a good idea? It will be more verbose for the human user. One advantage: all throttle groups can then be managed through qom-set/qom-get since they are owned by the qom tree.
Description: PGP signature