On 12/04/2020 17:40, Jens Axboe wrote: >> On 4/12/2020 5:07 AM, Jens Axboe wrote: >>> Thinking about this, I think the mistake here is using the SQ side for >>> the timeouts. Let's say you queue up N requests that are waiting, like >>> the poll. Then you arm a timeout, it'll now be at N + count before it >>> fires. We really should be using the CQ side for the timeouts. ... > Reason I bring up the other part is that Hrvoje's test case had other > cases as well, and the SQ vs CQ trigger is worth looking into. For > example, if we do: > > enqueue N polls > enqueue timeout, count == 2, t = 10s > enqueue 2 nops > > I'd logically expect the timeout to trigger when nop #2 is completed. > But it won't be, because we still have N polls waiting. What the count > == 2 is really saying (right now) is "trigger timeout when CQ passes SQ > by 2", which seems a bit odd. > time for this: 1. do we really want to change current behaviour? As you said, there may be users. 2. why a timeout can't be triggered by another timeout completion? There are bits adjusting req->sequence for enqueued timeouts up and down. I understand, that liburing hides timeouts from users, but handling them inconsistently in that sense from any other request is IMHO a bad idea. Can we kill it? 3. For your case, should it to fire exactly after those 2 nops? Or it can be triggered by previously completed requests (e.g. polls)? e.g. timeline as follows - enqueue polls - enqueue timeout - 2 polls completed - the timeout triggered by completion of polls - do nops The second one is what io_uring pdf says, and I'd prefer to have it. -- Pavel Begunkov
