From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: Manos Pitsidianakis <el13635@mail.ntua.gr>,
qemu-devel <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v3 5/7] block: add throttle block filter driver
Date: Wed, 9 Aug 2017 17:39:42 +0200 [thread overview]
Message-ID: <20170809153942.GI4213@localhost.localdomain> (raw)
In-Reply-To: <w51valwlrzc.fsf@maestria.local.igalia.com>
Am 09.08.2017 um 16:45 hat Alberto Garcia geschrieben:
> On Wed 09 Aug 2017 03:42:07 PM CEST, Manos Pitsidianakis wrote:
> > On Wed, Aug 09, 2017 at 02:36:20PM +0200, Alberto Garcia wrote:
> >>On Wed 09 Aug 2017 11:36:12 AM CEST, Manos Pitsidianakis wrote:
> >>> On Tue, Aug 08, 2017 at 05:04:48PM +0200, Alberto Garcia wrote:
> >>>>On Tue 08 Aug 2017 04:56:20 PM CEST, Manos Pitsidianakis wrote:
> >>>>>>> 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.
> >>>>
> >>>>Sorry I think it was me who misunderstood :-) Anyway in the new
> >>>>command-line API I would be more inclined to have limits defined using
> >>>>"-object throttle-group" and -drive would only reference the group id.
> >>>>
> >>>>I understand that this implies that it wouldn't be possible to create
> >>>>anonymous groups (at least not from the command line), is that a
> >>>>problem?
> >>>
> >>> We can accept anonymous groups if a user specifies limits but not a
> >>> group name in the throttle driver. (The only case where limits would
> >>> be acccepted)
> >>
> >>Yeah but that's only if we have the limits.iops-total=... options in the
> >>throttle driver. If we "remove limits from the throttle driver options
> >>and only create/config throttle groups via -object/object-add" we
> >>cannot
> >>do that.
> >
> > We can check that groups is not defined at the same time as limits,
>
> I'm not sure if I'm following the conversation anymore :-) let's try to
> recap:
>
> a) Groups are defined like this (with the current patches):
>
> -object throttle-group,id=foo,x-iops-total=100,x-..
>
> b) Throttle nodes are defined like this:
>
> -drive driver=throttle,file.filename=foo.qcow2, \
> limits.iops-total=...,throttle-group=bar
>
> c) Therefore limits can be defined either in (a) or (b)
>
> d) If we omit throttle-group=... in (b), we would create an anonymous
> group.
>
> e) The -drive syntax from (b) has the "problem" that it's possible to
> define several nodes with the same throttling group but different
> limits. The last one would win (as the legacy syntax does), but
> that's not something completely straightforward for the end user.
>
> f) The syntax from (b) also has the problem that there's one more
> place that needs code to parse throttling limits.
>
> g) We can solve (e) and (f) if we remove the limits.* options
> altogether from the throttling filter. In that case you would need
> to define a throttle-group object and use the throttle-group option
> of the filter node in all cases.
>
> h) If we remove the limits.* options we cannot have anonymous groups
> anymore (at least not using this API). My question is: is it a
> problem? What would we lose? What benefits do anonymous groups
> bring us?
As I understand it, basically only the convenience of begin able to
specify a limit directly in -drive rather than having to create an
-object and reference its ID.
> i) We can of course maintain the limits.* options, but disallow
> throttle-group when they are present. That way we would allow
> anonymous groups and we would solve the ambiguity problem described
> in (e). My question is: is it worth it?
Maybe not. Depends on how important we consider the convenience feature.
> >>> Not creating eponymous throttle groups via the throttle driver means
> >>> we don't need throttle_groups anymore, since even anonymous ones
> >>> don't need to be accounted for in a list.
> >>
> >>I don't follow you here, how else do you get a group by its name?
> >
> > If all eponymous groups are managed by the QOM tree, we should be able
> > to iterate over the object root container for all ThrottleGroups just
> > like qmp_query_iothreads() in iothread.c
>
> Mmm... can't we actually use the root container now already? (even with
> anonymous groups I mean). Why do we need throttle_groups?
Anonymous groups don't have a parent, so they aren't accessible through
the root container.
Kevin
next prev parent reply other threads:[~2017-08-09 15:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 9:54 [Qemu-devel] [PATCH v3 0/7] add throttle block driver filter Manos Pitsidianakis
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 1/7] block: move ThrottleGroup membership to ThrottleGroupMember Manos Pitsidianakis
2017-08-04 11:59 ` Alberto Garcia
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 2/7] block: add aio_context field in ThrottleGroupMember Manos Pitsidianakis
2017-08-04 12:14 ` Alberto Garcia
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 3/7] block: tidy ThrottleGroupMember initializations Manos Pitsidianakis
2017-08-04 12:35 ` Alberto Garcia
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 4/7] block: convert ThrottleGroup to object with QOM Manos Pitsidianakis
2017-08-01 15:47 ` Stefan Hajnoczi
2017-08-01 16:49 ` Manos Pitsidianakis
2017-08-02 10:39 ` Stefan Hajnoczi
2017-08-02 10:57 ` Manos Pitsidianakis
2017-08-02 14:43 ` Stefan Hajnoczi
2017-08-03 8:08 ` Kevin Wolf
2017-08-03 10:53 ` Stefan Hajnoczi
2017-08-03 11:17 ` Kevin Wolf
2017-08-03 12:29 ` Manos Pitsidianakis
2017-08-08 13:01 ` Alberto Garcia
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 5/7] block: add throttle block filter driver Manos Pitsidianakis
2017-08-01 16:14 ` Stefan Hajnoczi
2017-08-03 8:07 ` Kevin Wolf
2017-08-03 11:48 ` Manos Pitsidianakis
2017-08-03 12:05 ` Kevin Wolf
2017-08-03 11:58 ` Eric Blake
2017-08-03 13:56 ` Manos Pitsidianakis
2017-08-08 13:13 ` Alberto Garcia
2017-08-08 13:45 ` Manos Pitsidianakis
2017-08-08 14:53 ` Alberto Garcia
2017-08-08 14:56 ` Manos Pitsidianakis
2017-08-08 15:04 ` Alberto Garcia
2017-08-09 9:36 ` Manos Pitsidianakis
2017-08-09 12:36 ` Alberto Garcia
2017-08-09 13:42 ` Manos Pitsidianakis
2017-08-09 14:45 ` Alberto Garcia
2017-08-09 15:39 ` Kevin Wolf [this message]
2017-08-14 12:15 ` Manos Pitsidianakis
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 6/7] block: add BlockDevOptionsThrottle to QAPI Manos Pitsidianakis
2017-08-01 16:16 ` Stefan Hajnoczi
2017-07-31 9:54 ` [Qemu-devel] [PATCH v3 7/7] block: add throttle block filter driver interface tests Manos Pitsidianakis
2017-08-03 8:07 ` Kevin Wolf
2017-08-03 13:24 ` Manos Pitsidianakis
2017-08-03 13:32 ` Kevin Wolf
2017-08-03 13:52 ` Manos Pitsidianakis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170809153942.GI4213@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=el13635@mail.ntua.gr \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).