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