On 3/15/24 10:29 AM, Pavel Begunkov wrote:
> On 3/15/24 16:25, Jens Axboe wrote:
>> On 3/15/24 10:23 AM, Pavel Begunkov wrote:
>>> On 3/15/24 16:20, Jens Axboe wrote:
>>>> On 3/15/24 9:30 AM, Pavel Begunkov wrote:
>>>>> io_post_aux_cqe(), which is used for multishot requests, delays
>>>>> completions by putting CQEs into a temporary array for the purpose
>>>>> completion lock/flush batching.
>>>>>
>>>>> DEFER_TASKRUN doesn't need any locking, so for it we can put completions
>>>>> directly into the CQ and defer post completion handling with a flag.
>>>>> That leaves !DEFER_TASKRUN, which is not that interesting / hot for
>>>>> multishot requests, so have conditional locking with deferred flush
>>>>> for them.
>>>>
>>>> This breaks the read-mshot test case, looking into what is going on
>>>> there.
>>>
>>> I forgot to mention, yes it does, the test makes odd assumptions about
>>> overflows, IIRC it expects that the kernel allows one and only one aux
>>> CQE to be overflown. Let me double check
>>
>> Yeah this is very possible, the overflow checking could be broken in
>> there. I'll poke at it and report back.
>
> test() {
> if (!(cqe->flags & IORING_CQE_F_MORE)) {
> /* we expect this on overflow */
> if (overflow && (i - 1 == NR_OVERFLOW))
> break;
> fprintf(stderr, "no more cqes\n");
> return 1;
> }
> ...
> }
>
> It's this chunk. I think I silenced it with
>
> s/i - 1 == NR_OVERFLOW/i == NR_OVERFLOW/
>
> but it should probably be i >= NR_OVERFLOW or so
Yeah see other email, I did the latter. It's pushed out.
--
Jens Axboe
