[ Cc: qemu-block - noticed only now that it's missing ] Am 29.05.2017 um 22:57 hat Manos Pitsidianakis geschrieben: > On Mon, May 29, 2017 at 05:05:17PM +0200, Alberto Garcia wrote: > >On Sat 27 May 2017 09:56:03 AM CEST, Stefan Hajnoczi wrote: > >>A quirk in the current implementation is that the throttling limits > >>for the group are overwritten by each -drive throttling.group=group0. > >>Limits for all but the last -drive in a group are ignored. > > - bps or iops != 0 -> set the I/O limits of a throttling group. The > > selected device is moved to that group if it > > wasn't there yet. > > > > - bps and iops == 0 -> remove a device from a throttling group > > without touching that group's I/O limits. > > These are very unintuitive.
I agree, this is not an interface to extend, but one to get rid of. (Of course, we'll have to keep it around for a while because compatibility, but we should try to offer something better.) > However, even without considering backwards compatibility, I think > that using -object notation (eg "object-add > throttle-group,id=foo,iops=...) is intuitive in the case of groups, > but not when you need individual limits for each device as the syntax > would be too verbose. Of course the old interface covers that. > > In any case, is having multiple interfaces a problem or not? And, is > using QOM straightforward implementation-wise? We can have an interface for the throttling node that requires that you specify either a throttle group object name or the limits, but never both. If you specify the limits, this would just be a convenience function that creates the right QOM object internally. As for the implementation, QOM tends to be a bit heavy on boilerplate code, but I think it's not too bad otherwise. Kevin
