From: Kevin Wolf <kwolf@redhat.com>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Or Ozeri <oro@il.ibm.com>,
qemu-devel@nongnu.org, dupadhya@redhat.com,
to.my.trociny@gmail.com, qemu-block@nongnu.org,
dannyh@il.ibm.com, Stefan Hajnoczi <stefanha@redhat.com>,
pbonzini@redhat.com
Subject: Re: [PATCH v1 1/1] virtio-block: switch to blk_get_max_hw_transfer
Date: Fri, 13 Jan 2023 12:44:57 +0100 [thread overview]
Message-ID: <Y8FEObcExtXrcoSx@redhat.com> (raw)
In-Reply-To: <CAOi1vP95sznmAETC1ikqb5bxKueDZYd7HtEjM=7KerMSALYFuQ@mail.gmail.com>
Am 12.01.2023 um 21:28 hat Ilya Dryomov geschrieben:
> On Thu, Dec 9, 2021 at 10:34 AM Or Ozeri <oro@il.ibm.com> wrote:
> >
> > The blk_get_max_hw_transfer API was recently added in 6.1.0.
> > It allows querying an underlying block device its max transfer capability.
> > This commit changes virtio-blk to use this.
> >
> > Signed-off-by: Or Ozeri <oro@il.ibm.com>
> > ---
> > hw/block/virtio-blk.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> > index f139cd7cc9..1ba9a06888 100644
> > --- a/hw/block/virtio-blk.c
> > +++ b/hw/block/virtio-blk.c
> > @@ -458,7 +458,7 @@ static void virtio_blk_submit_multireq(BlockBackend *blk, MultiReqBuffer *mrb)
> > return;
> > }
> >
> > - max_transfer = blk_get_max_transfer(mrb->reqs[0]->dev->blk);
> > + max_transfer = blk_get_max_hw_transfer(mrb->reqs[0]->dev->blk);
> >
> > qsort(mrb->reqs, mrb->num_reqs, sizeof(*mrb->reqs),
> > &multireq_compare);
>
> Hi Or,
>
> Superficially, this makes sense to me.
I'm not sure I understand. This is not a passthrough device (unlike
scsi-generic), so why should we consider the hardware limits rather than
the kernel/other backend limits for read/write requests?
See the documentation of both fields:
/*
* Maximal transfer length in bytes. Need not be power of 2, but
* must be multiple of opt_transfer and bl.request_alignment, or 0
* for no 32-bit limit. For now, anything larger than INT_MAX is
* clamped down.
*/
uint32_t max_transfer;
/*
* Maximal hardware transfer length in bytes. Applies whenever
* transfers to the device bypass the kernel I/O scheduler, for
* example with SG_IO. If larger than max_transfer or if zero,
* blk_get_max_hw_transfer will fall back to max_transfer.
*/
uint64_t max_hw_transfer;
Is the real problem that max_transfer isn't right?
Kevin
next prev parent reply other threads:[~2023-01-13 11:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 9:28 [PATCH v1 0/1] virtio-block: switch to blk_get_max_hw_transfer Or Ozeri
2021-12-09 9:28 ` [PATCH v1 1/1] " Or Ozeri
2023-01-12 20:28 ` Ilya Dryomov
2023-01-13 11:44 ` Kevin Wolf [this message]
2023-01-30 10:48 ` Or Ozeri
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=Y8FEObcExtXrcoSx@redhat.com \
--to=kwolf@redhat.com \
--cc=dannyh@il.ibm.com \
--cc=dupadhya@redhat.com \
--cc=idryomov@gmail.com \
--cc=oro@il.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=to.my.trociny@gmail.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 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.