From: Elena <elena.ufimtseva@oracle.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, jag.raman@oracle.com,
john.g.johnson@oracle.com, john.levon@nutanix.com,
mst@redhat.com, pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: ioregionfd with io_uring IORING_OP_URING_CMD
Date: Tue, 7 Jun 2022 06:26:25 -0700 [thread overview]
Message-ID: <20220607132625.GA181696@heatpiped> (raw)
In-Reply-To: <Yp4V61lfTTN3QsT4@stefanha-x1.localdomain>
On Mon, Jun 06, 2022 at 03:57:47PM +0100, Stefan Hajnoczi wrote:
> Hi,
> During Elena Afanasova's Outreachy project we discussed whether
> ioregionfd should be a custom struct file_operations (anon inode) or a
> userspace-provided file (socketpair, UNIX domain socket, etc).
>
Hello Stefan,
> Back then it seemed more flexible and simpler to let userspace provide
> the file. It may be worth revisiting this decision in light of the
> recent io_uring IORING_OP_URING_CMD feature, which fits for this
> performance-critical interface.
>
And Paolo was asking about io_uring in the review of the initial
patches.
> IORING_OP_URING_CMD involves a new struct file_operations->uring_cmd()
> callback. It's a flexible userspace interface like ioctl(2) but designed
> to be asynchronous. ioregionfd can provide a uring_cmd() that reads a
> ioregionfd response from userspace and then writes the next ioregionfd
> request to userspace.
>
> This single operation merges the request/response so only 1 syscall is
> necessary per KVM MMIO/PIO exit instead of a read() + write(). Bypassing
> the net/socket infrastructure is likely to help too.
>
> It would be interesting to benchmark this and compare it against the
> existing userspace-provided file approach. Although it's not the same
> scenario, results for the Linux NVMe driver using ->uring_cmd() are
> promising:
> https://www.snia.org/educational-library/enabling-asynchronous-i-o-passthru-nvme-native-applications-2021
>
Yes, looks interesting, we were thinking about adding this.
> The downside is it requires more code than general purpose I/O. In
> addition to ->uring_cmd(), it's also worth implementing struct
> file_operations read/write/poll so traditional file I/O syscalls work
> for simple applications that don't want to use io_uring.
>
> It's possible to add ->uring_cmd() later but as a userspace developer I
> would prefer the ->uring_cmd() approach, so I'm not sure it's worth
> committing to the existing userspace-provided file approach?
Makes total sense. I am going to start working on this and will
come back with more questions.
Thank you!
Elena
>
> Stefan
next prev parent reply other threads:[~2022-06-07 13:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-06 14:57 ioregionfd with io_uring IORING_OP_URING_CMD Stefan Hajnoczi
2022-06-07 13:26 ` Elena [this message]
2022-06-07 14:08 ` 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=20220607132625.GA181696@heatpiped \
--to=elena.ufimtseva@oracle.com \
--cc=jag.raman@oracle.com \
--cc=john.g.johnson@oracle.com \
--cc=john.levon@nutanix.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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 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.