Re: Odd timeout behavior

[Hrvoje Zeba <zeba.hrvoje@gmail.com>]

On Fri, Apr 17, 2020 at 4:40 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> 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.
>

I still see io_uring as early development. I've had several breakages
when I upgraded the kernel so far. I'm fine with it.

> 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
>

Timeout fires on any cqes is the behavior I expected. I can see the
reasoning behind only triggering for sqes that come after the timeout
(io_uring_submit_and_wait() being the use-case) tho.

-- 
I doubt, therefore I might be.