public inbox for [email protected]
 help / color / mirror / Atom feed
From: Artyom Pavlov <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Subject: Re: Allow IORING_OP_ASYNC_CANCEL to cancel requests on other rings
Date: Wed, 12 Jul 2023 21:25:51 +0300	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

05.07.2023 21:32, Jens Axboe wrote:
> On 7/5/23 10:44?AM, Artyom Pavlov wrote:
>> Greetings!
>>
>> Right now when I want to cancel request which runs on a different ring
>> I have to use IORING_OP_MSG_RING with a special len value. CQEs with
>> res equal to this special value get intercepted by my code and
>> IORING_OP_ASYNC_CANCEL SQE gets created in the receiver ring with
>> user_data taken from the received message. This approach kind of
>> works, but not efficient (it requires additional round trip through
>> the ring) and somewhat fragile (it relies on lack of collisions
>> between the special value and potential error codes).
>>
>> I think it should be possible to add support for cancelling requests
>> on other rings to IORING_OP_ASYNC_CANCEL by introducing a new flag. If
>> the flag is enabled, then the fd field would be interpreted as fd of
>> another ring to which cancellation request should be sent. Using the
>> fd field would mean that the new flag would conflict with
>> IORING_ASYNC_CANCEL_FD, so it could be worth to use a different field
>> for receiver ring fd.
> This could certainly work, though I think it'd be a good idea to use a
> reserved field for the "other ring fd". As of right now, the
> 'splice_fd_in' descriptor field is not applicable to cancel requests, so
> that'd probably be the right place to put it.
>
> Some complications around locking here, as we'd need to grab the other
> ring lock. If ring A and ring B both cancel requests for each other,
> then there would be ordering concerns. But nothing that can't be worked
> around.
>
> Let me take a quick look at that.
Hi!

Any news?

 >If ring A and ring B both cancel requests for each other, then there 
would be ordering concerns.

I am not sure I understand the concern. Do you mean that task1 on ring1 
attempts to cancel task2 on ring2, while task2 attempts to cancel task1? 
I don't see how it's different when both tasks are on the same ring. 
Task2 may run when ring2 receives the cancellation request, but it looks 
similar to CQE for waking up task2 being already in competition ring. In 
both cases you would simply get -ENOENT in response to such SQE.

Best regards,
Artyom Pavlov.


  reply	other threads:[~2023-07-12 18:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 16:44 Allow IORING_OP_ASYNC_CANCEL to cancel requests on other rings Artyom Pavlov
2023-07-05 18:32 ` Jens Axboe
2023-07-12 18:25   ` Artyom Pavlov [this message]
2023-07-15 15:53     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox