Re: Odd timeout behavior

[Pavel Begunkov <asml.silence@gmail.com>]

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