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

The driver can be used with the syntax
-drive driver=throttle,file.filename=foo.qcow2, \

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

Attachment: signature.asc
Description: PGP signature

Reply via email to