On Mon, Jun 12, 2017 at 01:15:43PM +0200, Kevin Wolf wrote:
Am 08.06.2017 um 20:21 hat Manos Pitsidianakis geschrieben: to maintain compatibility with the existing interfaces. We will have to automatically insert or remove new nodes if 'block_set_io_throttle' is used, but let's not extend it. It only makes things complicated.If people are using new features, they will be using new interfaces and we can make them use more natural syntax. For example, we can expect that they create throttle nodes manually (management tools always, human users at least for more complicated cases). What we may want is to update the settings of a throttle node at runtime (though inserting a new filter and then removing the old one could do the trick as well). If we want to change the settings of a throttle node, then I think the appropriate low-level interface is bdrv_reopen(). We need to figure out whether we can expose a full bdrv_reopen() on QMP or whether we need more specific commands. I'd prefer finally doing the "real thing" rather than adding more and more special-case commands to update nodes.
So basically, restrict our involvement in the graph with 'block_set_io_throttle', which will only deal with editing the node at the top of the tree, just below BB? (Unless the group name instead of device name is specified). Can the user sufficiently manage a complex configuration on their own with existing interfaces (ie blockdev-add)?
I maintain my stance that I express off-list, which is that query-block should _only_ display limits that belong to the throttle node that was internally created for satisfying a 'block_set_io_throttle' request on a BlockBackend.
Assuming the answer to my first question is yes, that will always be the throttle node below the queried BB.
signature.asc
Description: PGP signature
