qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] Consolidate reads and writes in nbd block device into one common routine
Date: Tue, 28 Feb 2012 14:03:18 +0100	[thread overview]
Message-ID: <4F4CD096.5000309@redhat.com> (raw)
In-Reply-To: <4F4CCA17.7080802@msgid.tls.msk.ru>

Il 28/02/2012 13:35, Michael Tokarev ha scritto:
> On 28.02.2012 15:35, Paolo Bonzini wrote:
>> Il 28/02/2012 11:24, Michael Tokarev ha scritto:
>>> This removes quite some duplicated code.
> []
>>> +static int nbd_co_rwv(BlockDriverState *bs, int64_t sector_num,
>>> +                      int nb_sectors, QEMUIOVector *qiov, int iswrite)
>>
>> Call this nbd_co_rw, and please pass the whole request.type down.
> 
> Originally it is readV and writeV, so why it should not be rwV ?

It's more consistent with block.c.

> By passing whole request.type (NBD_CMD_WRITE or NBD_CMD_WRITE|NBD_CMD_FLAG_FUA
> or NBD_CMD_READ) the condition (iswrite currently) will be larger (request.type
> != NBD_CMD_READ).  Also, if someday we'll have additional flag for READ as we
> already do for write, whole thing will be even more difficult to read.

Sure, but why should a generic function deal with NBD_CMD_FLAG_FUA?

>>
>>>  {
>>>      BDRVNBDState *s = bs->opaque;
>>>      struct nbd_request request;
>>>      struct nbd_reply reply;
>>> +    int offset = 0;
>>>  
>>> -    request.type = NBD_CMD_WRITE;
>>> -    if (!bdrv_enable_write_cache(bs) && (s->nbdflags & NBD_FLAG_SEND_FUA)) {
>>> +    request.type = iswrite ? NBD_CMD_WRITE : NBD_CMD_READ;
>>> +    if (iswrite && !bdrv_enable_write_cache(bs) && (s->nbdflags & NBD_FLAG_SEND_FUA)) {
>>>          request.type |= NBD_CMD_FLAG_FUA;
>>>      }
>>> +    reply.error = 0;
>>> +
>>> +    /* we split the request into pieces of at most NBD_MAX_SECTORS size
>>> +     * and process them in a loop... */
>>> +    do {
>>> +        request.from = sector_num * 512;
>>> +        request.len = MIN(nb_sectors, NBD_MAX_SECTORS) * 512;
>>> +
>>> +        nbd_coroutine_start(s, &request);
>>> +        if (nbd_co_send_request(s, &request, iswrite ? qiov->iov : NULL, 0) == -1) {
>>
>> The last 0 needs to be offset.
> 
> Indeed, this is a bug.  I think I tested it with large requests
> but it looks like only for reads.
> 
>> ... but thinking more about it, why don't you leave
>> nbd_co_readv_1/nbd_co_writev_1 alone, and create a nbd_split_rw function
>> that takes a function pointer?
> 
> Because each of these nbd_co_*_1 does the same thing, the diff. is
> only quiv->iov vs NULL.  While reading the original code it was the
> first thing I did - consolidated nbd_co_*_1 into nbd_co_* ;)

And offset.  I needed to check that non-0 offsets are fine when the iov
is NULL; it's not obvious.

> Actually it might be a good idea to have single bdrv->bdrv_co_readwritev
> method instead of two -- the path of each read and write jumps between
> specific read-or-write routine and common readwrite routine several
> times.

Small amounts of duplicate code can be better than functions with many
ifs or complicated conditions.

> I see only one correction which needs (really!) to be done - that's
> fixing the bug with offset.  Do you still not agree?

I still disagree. :)  I will accept the patch with the function pointer
though.

Paolo

  reply	other threads:[~2012-02-28 13:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 10:24 [Qemu-devel] [PATCH v2] Consolidate reads and writes in nbd block device into one common routine Michael Tokarev
2012-02-28 11:35 ` Paolo Bonzini
2012-02-28 12:35   ` Michael Tokarev
2012-02-28 13:03     ` Paolo Bonzini [this message]
2012-02-28 13:16       ` Michael Tokarev

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=4F4CD096.5000309@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    /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).