From: Kevin Wolf <kwolf@redhat.com>
To: Peter Lieven <pl@dlhnet.de>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
pbonzini@redhat.com, hreitz@redhat.com,
marcandre.lureau@redhat.com, berrange@redhat.com,
philmd@linaro.org, armbru@redhat.com, jsnow@redhat.com,
thuth@redhat.com, Ronnie Sahlberg <ronniesahlberg@gmail.com>
Subject: Re: [PATCH] block/nfs: add support for libnfs v6
Date: Tue, 10 Mar 2026 14:41:21 +0100 [thread overview]
Message-ID: <abAfgVCdcP66IrGk@redhat.com> (raw)
In-Reply-To: <20260306142840.72923-1-pl@dlhnet.de>
Am 06.03.2026 um 15:28 hat Peter Lieven geschrieben:
> libnfs v6 added a new api structure for read and write requests.
>
> This effectively also adds zero copy read support for cases where
> the qiov coming from the block layer has only one vector.
>
> The .brdv_refresh_limits implementation is needed because libnfs v6
> silently dropped support for splitting large read/write request into
> chunks.
>
> Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
> Signed-off-by: Peter Lieven <pl@dlhnet.de>
Thanks, applied to the block branch.
> @@ -280,6 +307,13 @@ static int coroutine_fn nfs_co_preadv(BlockDriverState *bs, int64_t offset,
> }
> qemu_coroutine_yield();
>
> + if (my_buffer) {
> + if (task.ret > 0) {
> + qemu_iovec_from_buf(iov, 0, buf, task.ret);
> + }
> + g_free(buf);
> + }
I wonder if it wouldn't be easier to just always do the copy in the
callback. The only thing that would need to be version dependent is the
buffer that contains the actual data (the @data parameter in
nfs_co_generic_cb or the bounce buffer).
But I assume we'll touch this code again soon enough, because I saw that
libnfs recently added vectored reads. If we can use them, that would be
even more efficient. (But somehow it didn't add vectored writes at the
same time? Strange.)
Kevin
prev parent reply other threads:[~2026-03-10 13:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 14:28 [PATCH] block/nfs: add support for libnfs v6 Peter Lieven
2026-03-10 13:41 ` 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=abAfgVCdcP66IrGk@redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=pl@dlhnet.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
--cc=thuth@redhat.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