On Fri, May 31, 2024 at 12:21 AM Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 5/30/24 10:02 AM, Bernd Schubert wrote: > > > > > > 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). We have concluded pipe & splice isn't good for zero copy, and io_uring provides zc in async way, which is really nice for async application. > > If you have an interest in the zero copy, do chime in, it would > certainly help get some closure on that feature. I don't think anyone > disagrees it's a useful and needed feature, but there are different view > points on how it's best solved. Now generic sqe group feature is being added, and generic zero copy can be built over it easily, can you or anyone take a look? https://lore.kernel.org/linux-block/20240511001214.173711-1-ming.lei@xxxxxxxxxx/ Thanks, Ming
