On Tue, Aug 08, 2017 at 04:53:08PM +0200, Alberto Garcia wrote:
On Tue 08 Aug 2017 03:45:44 PM CEST, Manos Pitsidianakis wrote: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.That's what the current throttling API does, and I tend to agree that it's not completely straightforward (a few people have asked me the same question since this feature is available). If we're going to add a new API we could eliminate this ambiguity. After all the previous -drive throttling.iops-total=... would still be available, wouldn't it?
Indeed, it already is.
So basically if we have anonymous groups, we accept limits in the driver options but only without a group-name.In the commit message you do however have limits and a group name, is that a mistake? -drive driver=throttle,file.filename=foo.qcow2, \ limits.iops-total=...,throttle-group=bar
Sorry this wasn't clear, I'm actually proposing to remove limits from the throttle driver options and only create/config throttle groups via -object/object-add.
Description: PGP signature