Using IORING_FILE_INDEX_ALLOC cqe result as argument for linked op?

[martinetd]

I've come across the linked openat_direct + op with fixed index in file table, which avoids a round-trip with userspace just to schedule the next op based on the returned fd...
But IORING_FILE_INDEX_ALLOC has the same problem as non-direct open that one doesn't know the file index ahead of time, so next request cannot be queued ahead.

Is there any way of telling the ring to keep the cqe->res around and use that for next op?
I've skimmed through the tests and examples but cannot find any such pattern; also didn't see anything like that in the kernel code but could have missed something... It doesn't look like it'd be easy to implement so I guess I'll just have to bite the bullet and count in userspace if I want to see how much difference it makes.

Thanks!

[axboe]

If you want to use a known fd between two SQEs, then you cannot use the allocator for direct descriptors. That ends up being basically the same as a normal file descriptor, in that you'd need to know what fd is being picked. The only sane way to do that is to let the app manage and pick the descriptor, rather than let the kernel allocate it.

There's currently no support for passing information between SQEs, or from CQE to SQE. Something like the bpf for io_uring work would be needed for that.

[martinetd]

Thanks for confirming!

I've added a quick bitmap based on ffsl(3) to manage free indices myself; it's not difficult but was surprised there's no such readily available "lib" like kernel's include/linux/bitmap.h; not sure that'd make sense for liburing though so I guess things are good right now.

One more question with fixed files, I've been able to use them fine with e.g. new getdents that has needs_file = 1 in op struct, but for openat which doesn't it's not useable... Correct?
the prep does open->dfd = READ_ONCE(sqe->fd); so now that makes sense, but that wasn't clear at all from the man pages.. and makes crawling with the _direct variant pretty much impossible. Guess I'll have to give up on chaining here.