From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756650AbcG0OYd (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 Jul 2016 10:24:33 -0400
Received: from smtp02.citrix.com ([66.165.176.63]:9770 "EHLO SMTP02.CITRIX.COM"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756564AbcG0OYb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Jul 2016 10:24:31 -0400
X-IronPort-AV: E=Sophos;i="5.28,430,1464652800"; 
   d="scan'208";a="375749839"
Date: Wed, 27 Jul 2016 16:24:28 +0200
From: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
To: Bob Liu <bob.liu@oracle.com>
CC: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xenproject.org>,
        <konrad.wilk@oracle.com>
Subject: Re: [PATCH v3] xen-blkfront: dynamic configuration of per-vbd
 resources
Message-ID: <20160727142420.esp7aharesu45ixr@mac>
References: <1469589685-31630-1-git-send-email-bob.liu@oracle.com>
 <20160727105949.3rtlnl2zr4lpsvbc@mac> <57989921.5040504@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <57989921.5040504@oracle.com>
User-Agent: Mutt/1.6.2-neo (2016-06-11)
X-DLP: MIA2
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote:
> 
> On 07/27/2016 06:59 PM, Roger Pau Monné wrote:
> > On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote:
> > [...]
> >> +static ssize_t dynamic_reconfig_device(struct blkfront_info *info, ssize_t count)
> >> +{
> >> +	/*
> >> +	 * Prevent new requests even to software request queue.
> >> +	 */
> >> +	blk_mq_freeze_queue(info->rq);
> >> +
> >> +	/*
> >> +	 * Guarantee no uncompleted reqs.
> >> +	 */
> > 
> > I'm also wondering, why do you need to guarantee that there are no 
> > uncompleted requests? The resume procedure is going to call blkif_recover 
> > that will take care of requeuing any unfinished requests that are on the 
> > ring.
> > 
> 
> Because there may have requests in the software request queue with more segments than
> we can handle(if info->max_indirect_segments is reduced).
> 
> The blkif_recover() can't handle this since blk-mq was introduced,
> because there is no way to iterate the sw-request queues(blk_fetch_request() can't be used by blk-mq).
> 
> So there is a bug in blkif_recover(), I was thinking implement the suspend function of blkfront_driver like:

Hm, this is a regression and should be fixed ASAP. I'm still not sure I 
follow, don't blk_queue_max_segments change the number of segments the 
requests on the queue are going to have? So that you will only have to 
re-queue the requests already on the ring?

Waiting for the whole queue to be flushed before suspending is IMHO not 
acceptable, it introduces an unbounded delay during migration if the backend 
is slow for some reason.

Roger.