In continuation of the discussion at [0], here follows a proposal for a
new ThrottleGroup object defined through QOM.
Throttle groups are currently defined when instantiating a drive in the
command line,, eg.
-drive file=foo.qcow2,throttling.iops-total=100,throttling.group=bar
and also on QMP with the 'block_set_io_throttle' command, eg:
{ "execute": "block_set_io_throttle",
"arguments": {
"device": "virtio0",
"iops": 100,
"iops_rd": 0,
"iops_wr": 0,
"bps": 0,
"bps_rd": 0,
"bps_wr": 0
}
}
As part of my GSoC project, IO throttling is moved to a block filter
driver, which means multiple filter nodes sharing ThrottleGroup
instances, and also, chaining filter nodes. The old interface will be
retained as much as possible. By defining ThrottleGroups with QOM the
following interface can be used:
-drive file=foo.qcow2,throttling.group=bar \
-object throttle-group,iops-total=100,id=bar
which will be equivalent to the current command above. The
'block_set_io_throttle' command can be extended with a "group" argument,
that when defined instead of "device", will find and edit the object in
question. Users can hotplug ThrottleGroups with object-add in QMP/HMP,
then attach drives to a throttle group (ie adding a filter node in the
drive path that points to that throttle group) with an 'attach-throttle'
and detach with 'detach-throttle', each taking the drive and throttle
group name as arguments. An alternative (but uglier) approach would be
to use 'block_set_io_throttle' for this as well. Something that's also
sound is a 'block_set_throttle_groups' that takes a list of groups and a
drive as arguments. I think the last could be best if the relevant
function does not become complex.
All this means that existing configuration will not be redefined
everytime the object is referenced unless each limit is specified
explicitly, like it was mentioned in the previous discussion.
Regarding 'query-block'. This case is complicated by the fact that it
would be possible for a drive to have many nodes, thus the values
printed by 'query-block' might be inaccurate if they only report one of
the node configurations. The current approach is to report only the
first filter node in the BDS tree. A user with advanced throttling
configurations might have no need for this command.
I'm not certain about this, since this could be handled internally by an
application, but it might be useful to have queries to list all the
throttle groups that affect a drive, and to list all the drives in a
throttle group. Maybe defining the drives as a ThrottleGroup QOM
property will take care of the latter and also attaching/detaching
drives to a group through the property getter/setter. Thoughts?
[0] https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg06245.html