qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Fam Zheng <famz@redhat.com>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/6] block: Support byte-based aio callbacks
Date: Tue, 24 Apr 2018 19:15:24 +0200	[thread overview]
Message-ID: <20180424171524.GH4080@localhost.localdomain> (raw)
In-Reply-To: <7e74c08c-9086-ac07-fac4-8a75fb716f29@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3431 bytes --]

Am 24.04.2018 um 19:06 hat Eric Blake geschrieben:
> On 04/24/2018 10:40 AM, Kevin Wolf wrote:
> > Am 15.02.2018 um 20:28 hat Eric Blake geschrieben:
> >> We are gradually moving away from sector-based interfaces, towards
> >> byte-based.  Add new sector-based aio callbacks for read and write,
> >> to match the fact that bdrv_aio_pdiscard is already byte-based.
> >>
> >> Ideally, drivers should be converted to use coroutine callbacks
> >> rather than aio; but that is not quite as trivial (if we do that
> >> conversion, the null-aio driver will disappear), so for the
> >> short term, converting the signature but keeping things with aio
> >> is easier.  Once all drivers are converted, the sector-based aio
> >> callbacks will be removed.
> >>
> >> Signed-off-by: Eric Blake <eblake@redhat.com>
> >> ---
> >>  include/block/block_int.h |  6 ++++++
> >>  block/io.c                | 37 +++++++++++++++++++++++++++----------
> >>  2 files changed, 33 insertions(+), 10 deletions(-)
> >>
> 
> >> +++ b/block/io.c
> >> @@ -934,9 +934,11 @@ static int coroutine_fn bdrv_driver_preadv(BlockDriverState *bs,
> >>      sector_num = offset >> BDRV_SECTOR_BITS;
> >>      nb_sectors = bytes >> BDRV_SECTOR_BITS;
> >>
> >> -    assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> >> -    assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> >> -    assert((bytes >> BDRV_SECTOR_BITS) <= BDRV_REQUEST_MAX_SECTORS);
> >> +    if (!drv->bdrv_aio_preadv) {
> >> +        assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> >> +        assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> >> +        assert((bytes >> BDRV_SECTOR_BITS) <= BDRV_REQUEST_MAX_SECTORS);
> >> +    }
> > 
> > Hm, this is kind of ugly. Previously, we handled everything byte-aligned
> > in the first section, now we mix both in the second section.
> > 
> > I can see that you do this so you don't have to duplicate the acb and
> > coroutine yielding code below, but can we move things into the right
> > place in the final patch at least? That is, calculate sector_num and
> > nb_sectors only if all the byte-based interfaces weren't available.
> 
> Yeah, that's easy enough to squash into patch 6:
> 
> diff --git i/block/io.c w/block/io.c
> index ba767612931..49fabe8eeb1 100644
> --- i/block/io.c
> +++ w/block/io.c
> @@ -924,16 +924,13 @@ static int coroutine_fn
> bdrv_driver_preadv(BlockDriverState *bs,
>          return drv->bdrv_co_preadv(bs, offset, bytes, qiov, flags);
>      }
> 
> -    sector_num = offset >> BDRV_SECTOR_BITS;
> -    nb_sectors = bytes >> BDRV_SECTOR_BITS;
> -
> -    if (!drv->bdrv_aio_preadv) {
> -        assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> -        assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> -        assert((bytes >> BDRV_SECTOR_BITS) <= BDRV_REQUEST_MAX_SECTORS);
> -    }
> -
>      if (drv->bdrv_co_readv) {
> +        sector_num = offset >> BDRV_SECTOR_BITS;
> +        nb_sectors = bytes >> BDRV_SECTOR_BITS;
> +
> +        assert((offset & (BDRV_SECTOR_SIZE - 1)) == 0);
> +        assert((bytes & (BDRV_SECTOR_SIZE - 1)) == 0);
> +        assert((bytes >> BDRV_SECTOR_BITS) <= BDRV_REQUEST_MAX_SECTORS);
>          return drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
>      } else {
>          BlockAIOCB *acb;

Ah, yes. I thought of moving the code in the else block, but this works,
too. Maybe it's even a bit nicer.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2018-04-24 17:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15 19:28 [Qemu-devel] [PATCH 0/6] block: byte-based AIO read/write Eric Blake
2018-02-15 19:28 ` [Qemu-devel] [PATCH 1/6] block: Support byte-based aio callbacks Eric Blake
2018-04-24 15:40   ` Kevin Wolf
2018-04-24 17:06     ` Eric Blake
2018-04-24 17:15       ` Kevin Wolf [this message]
2018-04-24 19:16         ` Eric Blake
2018-02-15 19:28 ` [Qemu-devel] [PATCH 2/6] file-win32: Switch to byte-based callbacks Eric Blake
2018-02-15 19:28 ` [Qemu-devel] [PATCH 3/6] null: Switch to byte-based read/write Eric Blake
2018-04-24 15:52   ` Kevin Wolf
2018-04-24 17:00     ` Eric Blake
2018-04-24 17:19       ` Kevin Wolf
2018-04-24 17:40         ` Eric Blake
2018-02-15 19:28 ` [Qemu-devel] [PATCH 4/6] rbd: Switch to byte-based callbacks Eric Blake
2018-02-15 19:28 ` [Qemu-devel] [PATCH 5/6] vxhs: " Eric Blake
2018-02-15 19:28 ` [Qemu-devel] [PATCH 6/6] block: Drop last of the sector-based aio callbacks Eric Blake
2018-04-24 15:02 ` [Qemu-devel] [PATCH 0/6] block: byte-based AIO read/write Eric Blake
2018-04-24 19:13   ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180424171524.GH4080@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).