From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQdav-00025P-PC for qemu-devel@nongnu.org; Thu, 20 Mar 2014 10:05:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQdap-0006FP-Oe for qemu-devel@nongnu.org; Thu, 20 Mar 2014 10:05:17 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:56344 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQdap-0006Ea-ER for qemu-devel@nongnu.org; Thu, 20 Mar 2014 10:05:11 -0400 Date: Thu, 20 Mar 2014 15:05:09 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140320140509.GA3205@irqsave.net> References: <20140314155756.GC3324@irqsave.net> <20140317031231.GA28582@T430.nay.redhat.com> <20140318132747.GN4607@noname.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140318132747.GN4607@noname.str.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] n ways block filters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Fam Zheng , Stefan Hajnoczi , qemu-devel , Max Reitz , Stefan Hajnoczi The Tuesday 18 Mar 2014 =E0 14:27:47 (+0100), Kevin Wolf wrote : > Am 17.03.2014 um 17:02 hat Stefan Hajnoczi geschrieben: > > On Mon, Mar 17, 2014 at 4:12 AM, Fam Zheng wrote: > > > On Fri, 03/14 16:57, Beno=EEt Canet wrote: > > >> I discussed a bit with Stefan on the list and we came to the concl= usion that the > > >> block filter API need group support. > > >> > > >> filter group: > > >> ------------- > > >> > > >> My current plan to implement this is to add the following fields t= o the BlockDriver > > >> structure. > > >> > > >> int bdrv_add_filter_group(const char *name, QDict options); > > >> int bdrv_reconfigure_filter_group(const char *name, QDict options)= ; > > >> int bdrv_destroy_filter_group(const char *name); >=20 > Beno=EEt, your mail left me puzzled. You didn't really describe the > problem that you're solving, nor what the QDict options actually > contains or what a filter group even is. >=20 > > >> These three extra method would allow to create, reconfigure or des= troy a block > > >> filter group. A block filter group contain the shared or non share= d state of the > > >> blockfilter. For throttling it would contains the ThrottleState st= ructure. > > >> > > >> Each block filter driver would contains a linked list of linked li= st where the > > >> BDS are registered grouped by filter groups state. > > > > > > Sorry I don't fully understand this. Does a filter group contain mu= ltiple block > > > filters, and every block filter has effect on multiple BDSes? Could= you give an > > > example? > >=20 > > Just to why a "group" mechanism is useful: > >=20 > > You want to impose a 2000 IOPS limit for the entire VM. Currently > > this is not possible because each drive has its own throttling state. > >=20 > > We need a way to say certain drives are part of a group. All drives > > in a group share the same throttling state and therefore a 2000 IOPS > > limit is shared amongst them. >=20 > Now at least I have an idea what you're all talking about, but it's > still not obvious to me how the three functions from above solve your > problem or how they work in detail. >=20 > The obvious solution, using often discussed blockdev-add concepts, is: > ______________ > virtio-blk_A --> | | --> qcow2_A --> raw-posix_A > | throttling | > virtio_blk_B --> |____________| --> qcow2_B --> nbd_B My proposal would be: ______________ virtio-blk_A --> | BDS 1 | --> qcow2_A --> raw-posix_A |____________| | _____|________ | | The shared state is the state of a BDS g= roup | Shared | It's stored in a static linked list of t= he | State | block/throttle.c module. It has a name a= nd contains a |____________| throttle state structure. | _____|________ | BDS 2 | virtio_blk_B --> |____________| --> qcow2_B --> nbd_B The name of the shared state is the throttle group name. The three added methods are used to add, configure and destroy such share= d states. The benefit of this aproach is that we don't need to add a special slot m= echanism and that removing BDS 2 would be easy. Your approach don't deal with the fact that the throttling group membersh= ip can be changed dynamically while the vm is running: for example adding qcow2_= C and removing qcow2_B should be made easy. Best regards Beno=EEt >=20 > That is, the I/O throttling BDS is referenced by two devices instead of > just one and it associates one 'input' with one 'output'. Once we have > BlockBackend, we would have two BBs, but still only one throttling > BDS. >=20 > The new thing that you get there is that the throttling driver has > not only multiple parents (that part exists today), but it behaves > differently depending on who called it. So we need to provide some way > for one BDS to expose multiple slots or whatever you want to call them > that users can attach to. >=20 > This is, by the way, the very same thing as would be required for > exposing qcow2 internal snapshots (read-only) while the VM is running. >=20 > Kevin >=20