What happens if io_uring_get_sqe returns NULL?

[ioquatix]

polyphony/ext/polyphony/backend_io_uring.c

Line 247 in b10ae24

struct io_uring_sqe *sqe = io_uring_get_sqe(&backend->ring);

[ioquatix]

		struct io_uring_sqe *sqe = NULL;
		
		while (!sqe) {
			io_uring_get_sqe(&data->ring);
			rb_thread_schedule();
		}

This doesn't seem ideal. Can we assume that after calling io_uring_submit there will be sqe available in every case?

It also seems like we would encounter race condition.

if (data->polling) { // it's true because we called some io_uring blocking method
  sqe = ...
  
  // data->polling is now 0 or becomes zero during the next call
  io_uring_submit(...) // boom thread unsafe submit
}

[noteflakes]

I don't have a perfect answer to that situation. Currently the backend holds a counter for prepared SQEs, and will call io_uring_submit only if the counter reaches the limit (which is the size of the SQ). Otherwise, any deferred SQEs will be submitted before polling for completions. Notice the pretty large SQ/CQ size - 2048 entries.

I guess a way to test this mechanism would be to use a much smaller value - maybe 8 entries, than launch a much larger number of IO ops from different fibers, see if this causes any problems. I'll put it on my TODO list.

I did think about the possibility of doing a loop if io_uring_get_sqe fails, maybe do a nonblocking poll for events. It's not clear to me though that this is the correct way of doing this. I can't find it right now on the liburing issue list, but I seem to remember something about io_uring being able to buffer more pending SQEs than the limit as long as you submit them.

[ioquatix]

Yes it's also my (perhaps incorrect) understanding that the SQE is just for event submission but you can have many more inflight requests than just the size of the SQE, as long as you submit it before polling/selecting.