On 5/14/20 10:18 AM, Pavel Begunkov wrote: > On 14/05/2020 18:53, Jens Axboe wrote: >> On 5/14/20 9:37 AM, Pavel Begunkov wrote: >> Hmm yes good point, it should work pretty easily, barring the use cases >> that do IRQ complete. But that was also a special case with the other >> cache. >> >>> BTW, there will be a lot of problems to make either work properly with >>> IORING_FEAT_SUBMIT_STABLE. >> >> How so? Once the request is setup, any state should be retained there. > > If a late alloc fails (e.g. in __io_queue_sqe()), you'd need to file a > CQE with an error. If there is no place in CQ, to postpone the > completion it'd require an allocated req. Of course it can be dropped, > but I'd prefer to have strict guarantees. > > That's the same reason, I have a patch stashed, that grabs links from > SQ atomically (i.e. take all SQEs of a link or none). OK, I see what you mean. Yeah there's definitely some quirkiness associated with deferring the allocation. I'm currently just working off the idea that we just need to fix the refcounts, using a relaxed version for the cases where we don't have shared semantics. We basically only need that for requests with out-of-line completions, like irq completions or async completions. -- Jens Axboe
