> I've been struggling a bit with how to make this reliable, and I'm not
> so sure there's a way to do that. Let's say an application sets up a
> ring with 8 sq entries, which would then default to 16 cq entries. With
> this patch, we'd allow 16 ios inflight. But what if the application does
> 
> for (i = 0; i < 32; i++) {
> 	sqe = get_sqe();
> 	prep_sqe();
> 	submit_sqe();
> }
> 
> And then directly proceeds to:
> 
> do {
> 	get_completions();
> } while (has_completions);
> 
> As long as fewer than 16 requests complete before we start reaping,
> we don't lose any events. Hence there's a risk of breaking existing
> setups with this, even though I don't think that's a high risk.
> 

I think, this should be considered as an erroneous usage of the API.
It's better to fail ASAP than to be surprised in a production
system, because of non-deterministic nature of such code. Even worse
with trying to debug such stuff. 

As for me, cases like below are too far-fetched

for (i = 0; i < n; i++)
	submit_read_sqe()
for (i = 0; i < n; i++) {
	device_allow_next_read()
	get_single_cqe()
}


> We probably want to add some sysctl limit for this instead. But then
> the question is, what should that entry (or entries) be?
> 

-- 
Pavel Begunkov