From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdZg0-0002Lx-TL for qemu-devel@nongnu.org; Thu, 02 Apr 2015 03:36:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdZfv-0004tV-Qb for qemu-devel@nongnu.org; Thu, 02 Apr 2015 03:36:32 -0400 Received: from smtp3.mundo-r.com ([212.51.32.191]:39379 helo=smtp4.mundo-r.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdZfv-0004tM-JA for qemu-devel@nongnu.org; Thu, 02 Apr 2015 03:36:27 -0400 Date: Thu, 2 Apr 2015 09:36:23 +0200 From: Alberto Garcia Message-ID: <20150402073623.GA14811@igalia.com> References: <3060954d506be499c26d07ba4624dd33cd7b002d.1427732020.git.berto@igalia.com> <20150401144451.GD2777@fam-t430.nay.redhat.com> <20150401151830.GB28058@igalia.com> <20150402032630.GC15412@fam-t430.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150402032630.GC15412@fam-t430.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH 4/7] throttle: Add throttle group support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On Thu, Apr 02, 2015 at 11:26:30AM +0800, Fam Zheng wrote: > > > Thinking about this, I'd slightly prefer a canonical throttle > > > group definition rather than patching the existing parameters: > > > > > > -object throttle-group,id=tg0,bps=100,iops=200,iops-max=1000 \ > > > -drive file=foo,id=foo,throttle-group=tg0 \ > > > -drive file=bar,id=bar,throttle-group=tg0 \ > > > > > > and error out if "bps=" etc are specified together with > > > "throttle-group=" in -drive. > > > > > > And in QMP, add block_set_io_throttle_group which works together > > > with object-add. > > > My first impression is that the idea is feasible, but I'm unsure > > at the moment of its complexity or possible side effects. > > I think it is a cleaner model and easier to understand. What > complexity are you referring to? The changes on the code. At first sight it seems that it should not be too difficult to convert the current implementation (and API) into the one you are proposing, but I'll wait for a few days to hear other opinions before attempting to rewrite it :) Berto