From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Sunny Zhu" <sunnyzhyy@qq.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org, hreitz@redhat.com
Subject: Re: [PATCH] block: change type of bytes from int to int64_t for *bdrv_aio_pdiscard
Date: Fri, 25 Apr 2025 17:36:54 +0200 [thread overview]
Message-ID: <aAusFsX7FwnElrNf@redhat.com> (raw)
In-Reply-To: <zd2plm54sqdos4oqsd4lbukzozupboivu4pueawwtxrmtsg5q4@ay2rhlohwjub>
Am 24.04.2025 um 19:40 hat Eric Blake geschrieben:
> On Tue, Apr 22, 2025 at 09:11:51AM +0200, Philippe Mathieu-Daudé wrote:
> > Hi Eric,
> >
> > On 21/4/25 17:03, Eric Blake wrote:
> > > On Mon, Apr 21, 2025 at 12:19:14AM +0800, Sunny Zhu wrote:
> > > > Keep it consistent with *bdrv_co_pdiscard.
> > > >
> > > > Currently, there is no BlockDriver implemented the bdrv_aio_pdiscard() function,
> > > > so we don’t need to make any adaptations either.
> > >
> > > If there are no drivers implementing the callback, then why have it?
> > > I think we have been moving towards more coroutine-based callbacks and
> > > away from the aio callbacks; if so, should we instead be deleting this
> > > callback as stale code?
> >
> > Could we add a comment in BlockDriver prototypes about prefering co over
> > aio implementations, possibly mentioning them as legacy?
>
> Thinking about this a bit more (but you'll definitely want Kevin's
> opinion, not just mine):
>
> $ git grep '\.bdrv_aio_'
> block/file-win32.c: .bdrv_aio_preadv = raw_aio_preadv,
> block/file-win32.c: .bdrv_aio_pwritev = raw_aio_pwritev,
> block/file-win32.c: .bdrv_aio_flush = raw_aio_flush,
> block/file-win32.c: .bdrv_aio_preadv = raw_aio_preadv,
> block/file-win32.c: .bdrv_aio_pwritev = raw_aio_pwritev,
> block/file-win32.c: .bdrv_aio_flush = raw_aio_flush,
> block/iscsi.c: .bdrv_aio_ioctl = iscsi_aio_ioctl,
> block/iscsi.c: .bdrv_aio_ioctl = iscsi_aio_ioctl,
> block/null.c: .bdrv_aio_preadv = null_aio_preadv,
> block/null.c: .bdrv_aio_pwritev = null_aio_pwritev,
> block/null.c: .bdrv_aio_flush = null_aio_flush,
>
> file-win32.c looks to be the major client of remaining aio interfaces.
> How hard would it be to convert those over to coroutines?
Not terribly complicated. In case of doubt, they remain callback based
internally and just yield until the callback reenters the coroutine.
For file-win32 specifically, paio_submit() can be modified to call
thread_pool_submit_co(), which already does this. The win32-aio paths
won't necessarily become simpler, but that's okay.
> iscsi.c uses aio only for ioctl. How hard would it be to convert it
> in the same way that we converted read/write/flush back in commit
> 063c3378?
iscsi_aio_ioctl() could probably be simplified a bit when the callback
is moved into the function itself, especially for the case of
iscsi_ioctl_handle_emulated().
> null.c provides aio interfaces solely for benchmarking purposes - but
> if it is the only remaining client of aio interfaces, it would be nice
> to just rip out support for null-aio: and rely solely on null:
null-aio is specifically an AIO based version, I think mainly to test
performance of AIO vs. coroutines. If we get rid of the AIO interfaces,
then we can probably just remove the whole null-aio driver. (Or rather,
make it an alias of null-co for now and deprecate it.)
> It sounds like we are close enough to a generic cleanup of detritus
> that it would be better to just finish the job than to add a comment
> about preferring co over aio.
Agreed.
Kevin
prev parent reply other threads:[~2025-04-25 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-20 16:19 [PATCH] block: change type of bytes from int to int64_t for *bdrv_aio_pdiscard Sunny Zhu
2025-04-21 15:03 ` Eric Blake
2025-04-21 17:33 ` Sunny Zhu
2025-04-22 7:11 ` Philippe Mathieu-Daudé
2025-04-24 17:40 ` Eric Blake
2025-04-25 15:36 ` Kevin Wolf [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=aAusFsX7FwnElrNf@redhat.com \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sunnyzhyy@qq.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).