On Sun, 13 Oct 2024 at 23:20, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote: > > > > On 10/12/24 16:38, Jens Axboe wrote: > > That may indeed be a decent idea for this too. You don't even need fancy > > tagging, you can just use the cqe index for your tag too, as it should > > not be bigger than the the cq ring space. Then you can get away with > > just using normal cqe sizes, and just have a shared region between the > > two where data gets written by the uring_cmd completion, and the app can > > access it directly from userspace. > > Would be good if Miklos could chime in here, adding back mmap for headers > wouldn't be difficult, but would add back more fuse-uring startup and > tear-down code. My worry is making the API more complex, OTOH I understand the need for io_uring to refrain from adding fuse specific features. Also seems like io_uring is accounting some of the pinned memory, but for the queues themselves it does not do that, even though the max number of sqes (32k) can take substantial amount of memory. Growing the cqe would make this worse, but this could be fixed by adding the missing accounting, possibly only if using non-standard cqe sizes to avoid breaking backward comatibility. Thanks, Miklos
