From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41972)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1W4JKM-0003Tl-0u
	for qemu-devel@nongnu.org; Fri, 17 Jan 2014 18:59:59 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1W4JKH-00041F-0L
	for qemu-devel@nongnu.org; Fri, 17 Jan 2014 18:59:53 -0500
Received: from paradis.irqsave.net ([62.212.105.220]:47757)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1W4JKG-000417-Kw
	for qemu-devel@nongnu.org; Fri, 17 Jan 2014 18:59:48 -0500
Date: Fri, 17 Jan 2014 23:42:58 +0100
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20140117224258.GB7739@irqsave.net>
References: <1389968119-24771-1-git-send-email-kwolf@redhat.com>
	<1389968119-24771-3-git-send-email-kwolf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <1389968119-24771-3-git-send-email-kwolf@redhat.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v3 02/29] block: Inherit opt_transfer_length
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: pl@kamp.de, qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, xiawenc@linux.vnet.ibm.com

Le Friday 17 Jan 2014 =E0 15:14:52 (+0100), Kevin Wolf a =E9crit :
> When there is a format driver between the backend, it's not guaranteed
> that exposing the opt_transfer_length for the format driver results in
> the optimal requests (because of fragmentation etc.), but it can't make
> things worse, so let's just do it.
>=20
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
> Reviewed-by: Max Reitz <mreitz@redhat.com>
> ---
>  block.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>=20
> diff --git a/block.c b/block.c
> index 99e69da..20f85cb 100644
> --- a/block.c
> +++ b/block.c
> @@ -485,7 +485,25 @@ static int bdrv_refresh_limits(BlockDriverState *b=
s)
> =20
>      memset(&bs->bl, 0, sizeof(bs->bl));
> =20
> -    if (drv && drv->bdrv_refresh_limits) {
> +    if (!drv) {
> +        return 0;
> +    }
> +
> +    /* Take some limits from the children as a default */
> +    if (bs->file) {
> +        bdrv_refresh_limits(bs->file);
> +        bs->bl.opt_transfer_length =3D bs->file->bl.opt_transfer_lengt=
h;
> +    }
> +
> +    if (bs->backing_hd) {
> +        bdrv_refresh_limits(bs->backing_hd);
> +        bs->bl.opt_transfer_length =3D
> +            MAX(bs->bl.opt_transfer_length,
> +                bs->backing_hd->bl.opt_transfer_length);
> +    }
> +
> +    /* Then let the driver override it */
> +    if (drv->bdrv_refresh_limits) {
>          return drv->bdrv_refresh_limits(bs);
>      }

Reviewed-by: Beno=EEt Canet <benoit@irqsave.net>
> =20
> --=20
> 1.8.1.4
>=20
>=20