All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Daniel Verkamp <dverkamp@chromium.org>
Cc: Max Gurtovoy <mgurtovoy@nvidia.com>,
	mst@redhat.com, virtualization@lists.linux-foundation.org,
	virtio-dev@lists.linux.dev, oren@nvidia.com, parav@nvidia.com
Subject: Re: [PATCH 1/1] virtio-blk: Add description for blk_size field
Date: Wed, 2 Oct 2024 09:42:17 -0400	[thread overview]
Message-ID: <20241002134217.GA1362405@fedora.redhat.com> (raw)
In-Reply-To: <CABVzXA=wov8OgADXbDiVVnhncc=zgET4MAGd3H1pr26XS38JBw@mail.gmail.com>

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

On Mon, Sep 30, 2024 at 06:45:23PM -0700, Daniel Verkamp wrote:
> From my point of view, it would be fine to clarify a few things:
> - blk_size should (not must) be the logical block size of the
> underlying storage device
> - data should (not must) be a multiple of blk_size for best performance
> 
> And maybe:
> - devices may choose to return IOERR if a driver submits an I/O
> request that does not conform to the above recommendations (but this
> conflicts with the "performance"-related wording that exists now)

QEMU's virtio-blk implementation returns IOERR when the driver submits
VIRTIO_BLK_T_IN/VIRTIO_BLK_T_OUT requests that are not aligned to the
logical block size:
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/block/virtio-blk.c#L367

Although I interpret the virtio-blk spec in the same way as you
(blk_size is just a hint for optimal performance), I guess in practice
drivers align requests to blk_size.

Adding a note that devices may return IOERR is worthwhile. It will tell
driver authors not to expect device implementations to accept misaligned
requests.

Stefan

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

  reply	other threads:[~2024-10-02 13:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-25 14:52 [PATCH 1/1] virtio-blk: Add description for blk_size field Max Gurtovoy
2024-09-25 20:57 ` Daniel Verkamp
2024-09-25 23:42   ` Max Gurtovoy
2024-09-26 21:44     ` Daniel Verkamp
2024-09-28  0:22       ` Max Gurtovoy
2024-10-01  1:45         ` Daniel Verkamp
2024-10-02 13:42           ` Stefan Hajnoczi [this message]
2024-10-02 23:56           ` Daniel Verkamp
2024-10-06 11:35             ` Max Gurtovoy
2024-10-08  1:58               ` Daniel Verkamp
2024-10-08 20:09             ` Stefan Hajnoczi

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=20241002134217.GA1362405@fedora.redhat.com \
    --to=stefanha@redhat.com \
    --cc=dverkamp@chromium.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=mst@redhat.com \
    --cc=oren@nvidia.com \
    --cc=parav@nvidia.com \
    --cc=virtio-dev@lists.linux.dev \
    --cc=virtualization@lists.linux-foundation.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.