ioregionfd with io_uring IORING_OP_URING_CMD

[Stefan Hajnoczi]

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).

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.

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

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?

Stefan

signature.asc
Description: PGP signature