On 5/30/24 17:36, Kent Overstreet wrote: > On Wed, May 29, 2024 at 08:00:35PM +0200, Bernd Schubert wrote: >> From: Bernd Schubert <bschubert@xxxxxxx> >> >> This adds support for uring communication between kernel and >> userspace daemon using opcode the IORING_OP_URING_CMD. The basic >> appraoch was taken from ublk. The patches are in RFC state, >> some major changes are still to be expected. >> >> Motivation for these patches is all to increase fuse performance. >> In fuse-over-io-uring requests avoid core switching (application >> on core X, processing of fuse server on random core Y) and use >> shared memory between kernel and userspace to transfer data. >> Similar approaches have been taken by ZUFS and FUSE2, though >> not over io-uring, but through ioctl IOs > > What specifically is it about io-uring that's helpful here? Besides the > ringbuffer? > > So the original mess was that because we didn't have a generic > ringbuffer, we had aio, tracing, and god knows what else all > implementing their own special purpose ringbuffers (all with weird > quirks of debatable or no usefulness). > > It seems to me that what fuse (and a lot of other things want) is just a > clean simple easy to use generic ringbuffer for sending what-have-you > back and forth between the kernel and userspace - in this case RPCs from > the kernel to userspace. > > But instead, the solution seems to be just toss everything into a new > giant subsystem? Hmm, initially I had thought about writing my own ring buffer, but then io-uring got IORING_OP_URING_CMD, which seems to have exactly what we need? From interface point of view, io-uring seems easy to use here, has everything we need and kind of the same thing is used for ublk - what speaks against io-uring? And what other suggestion do you have? I guess the same concern would also apply to ublk_drv. Well, decoupling from io-uring might help to get for zero-copy, as there doesn't seem to be an agreement with Mings approaches (sorry I'm only silently following for now). >From our side, a customer has pointed out security concerns for io-uring. My thinking so far was to implemented the required io-uring pieces into an module and access it with ioctls... Which would also allow to backport it to RHEL8/RHEL9. Thanks, Bernd
