On Wed, Jun 12, 2024 at 03:53:42PM GMT, Bernd Schubert wrote: > I will definitely look at it this week. Although I don't like the idea > to have a new kthread. We already have an application thread and have > the fuse server thread, why do we need another one? Ok, I hadn't found the fuse server thread - that should be fine. > > > > The next thing I was going to look at is how you guys are using splice, > > we want to get away from that too. > > Well, Ming Lei is working on that for ublk_drv and I guess that new approach > could be adapted as well onto the current way of io-uring. > It _probably_ wouldn't work with IORING_OP_READV/IORING_OP_WRITEV. > > https://lore.gnuweeb.org/io-uring/20240511001214.173711-6-ming.lei@xxxxxxxxxx/T/ > > > > > Brian was also saying the fuse virtio_fs code may be worth > > investigating, maybe that could be adapted? > > I need to check, but really, the majority of the new additions > is just to set up things, shutdown and to have sanity checks. > Request sending/completing to/from the ring is not that much new lines. What I'm wondering is how read/write requests are handled. Are the data payloads going in the same ringbuffer as the commands? That could work, if the ringbuffer is appropriately sized, but alignment is a an issue. We just looked up the device DMA requirements and with modern NVME only 4 byte alignment is required, but the block layer likely isn't set up to handle that. So - prearranged buffer? Or are you using splice to get pages that userspace has read into into the kernel pagecache?
