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.
