All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Paolo Bonzini <pbonzini@redhat.com>
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 17:16:46 +0400	[thread overview]
Message-ID: <4F4CD3BE.2010309@msgid.tls.msk.ru> (raw)
In-Reply-To: <4F4CD096.5000309@redhat.com>

On 28.02.2012 17:03, Paolo Bonzini wrote:
> 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?

I can pass both "iswrite" and request.type here - to avoid possible
complications in the area of adding more nbd-specific meanings/flags
to request.type.  But that becomes more ugly.

[]
>>> ... 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.

It isn't indeed.  Both send_request and recv_reply only checks iov
and ignores offset if iov is NULL.

>> 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.

Sure thing.  But when the code path is so twisted - common->specific->
common-> specific - it makes very difficult to get the bigger picture.

>> 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.

With separate nbd_co_*_1 it isn't worth the effort.  When it all is in a
_small_ single routine (the resulting function is actually very small),
whole logic is immediately visible.  In particular, the FUA bit which
is set for every _part_ of write request - it wasn't visible till I
integrated nbd_co_writev_1 into nbd_co_writev.

Thanks,

/mjt

      reply	other threads:[~2012-02-28 13:17 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
2012-02-28 13:16       ` Michael Tokarev [this message]

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=4F4CD3BE.2010309@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=pbonzini@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.