From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPu4q-0000Gs-Ip for qemu-devel@nongnu.org; Tue, 18 Mar 2014 09:29:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPu4k-0006z0-JA for qemu-devel@nongnu.org; Tue, 18 Mar 2014 09:29:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPu4k-0006yw-B6 for qemu-devel@nongnu.org; Tue, 18 Mar 2014 09:29:02 -0400 Date: Tue, 18 Mar 2014 14:27:47 +0100 From: Kevin Wolf Message-ID: <20140318132747.GN4607@noname.str.redhat.com> References: <20140314155756.GC3324@irqsave.net> <20140317031231.GA28582@T430.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: 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: Stefan Hajnoczi Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Fam Zheng , qemu-devel , Stefan Hajnoczi , Max Reitz 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 conclus= ion that the > >> block filter API need group support. > >> > >> filter group: > >> ------------- > >> > >> My current plan to implement this is to add the following fields to = 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); 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. > >> These three extra method would allow to create, reconfigure or destr= oy a block > >> filter group. A block filter group contain the shared or non shared = state of the > >> blockfilter. For throttling it would contains the ThrottleState stru= cture. > >> > >> Each block filter driver would contains a linked list of linked list= where the > >> BDS are registered grouped by filter groups state. > > > > Sorry I don't fully understand this. Does a filter group contain mult= iple block > > filters, and every block filter has effect on multiple BDSes? Could y= ou 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. 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. 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 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. 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. 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. Kevin