Re: Sending CQE to a different ring

[Artyom Pavlov <newpavlov@gmail.com>]

10.03.2022 18:46, Jens Axboe wrote:
> On 3/10/22 8:43 AM, Jens Axboe wrote:
>> On 3/10/22 8:36 AM, Artyom Pavlov wrote:
>>> After thinking about it a bit, I think this approach has one serious
>>> disadvantage: you lose successful result value of the initial request.
>>> Imagine we submit IORING_OP_READ and link IORING_OP_WAKEUP_RING to it.
>>> If the request is completed successfully, both ring1 and ring2 will
>>> lose number of read bytes.
>>
>> But you know what the result is, otherwise you would've gotten a cqe
>> posted if it wasn't what you asked for.
> 
> Can also be made more explicit by setting sqe->len to what you set the
> original request length to, and then pass that back in the cqe->res
> instead of using the pid from the task that sent it. Then you'd have it
> immediately available. Might make more sense than the pid, not sure
> anyone would care about that?

Maybe I am missing something, but we only know that the request to which
IORING_OP_WAKEUP_RING was linked completed successfully. How exactly do 
you retrieve the number of read bytes with the linking aproach?

Yes, passing positive result value would make more sense than PID of 
submitter, which is rarely, if ever, needed. IIUC we would not be able 
to use linking with such approach, since sqe->len has to be set in user 
code based on a received CQE, but I guess it should be fine in practice.