public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Ming Lei <[email protected]>,
	[email protected], [email protected]
Cc: ZiyangZhang <[email protected]>
Subject: Re: [PATCH 00/10] io_uring/ublk: exit notifier support
Date: Mon, 18 Sep 2023 06:54:33 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 9/17/23 10:10 PM, Ming Lei wrote:
> Hello,
> 
> In do_exit(), io_uring needs to wait pending requests.
> 
> ublk is one uring_cmd driver, and its usage is a bit special by submitting
> command for waiting incoming block IO request in advance, so if there
> isn't any IO request coming, the command can't be completed. So far ublk
> driver has to bind its queue with one ublk daemon server, meantime
> starts one monitor work to check if this daemon is live periodically.
> This way requires ublk queue to be bound one single daemon pthread, and
> not flexible, meantime the monitor work is run in 3rd context, and the
> implementation is a bit tricky.
> 
> The 1st 3 patches adds io_uring task exit notifier, and the other
> patches converts ublk into this exit notifier, and the implementation
> becomes more robust & readable, meantime it becomes easier to relax
> the ublk queue/daemon limit in future, such as not require to bind
> ublk queue with single daemon.

The normal approach for this is to ensure that each request is
cancelable, which we need for other things too (like actual cancel
support). Why can't we just do the same for ublk?

-- 
Jens Axboe


  parent reply	other threads:[~2023-09-18 12:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18  4:10 [PATCH 00/10] io_uring/ublk: exit notifier support Ming Lei
2023-09-18  4:10 ` [PATCH 01/10] io_uring: allocate ctx id and build map between id and ctx Ming Lei
2023-09-18  4:10 ` [PATCH 02/10] io_uring: pass io_uring_ctx->id to uring_cmd Ming Lei
2023-09-18  4:10 ` [PATCH 03/10] io_uring: support io_uring notifier for uring_cmd Ming Lei
2023-09-18  4:11 ` [PATCH 04/10] ublk: don't get ublk device reference in ublk_abort_queue() Ming Lei
2023-09-18  4:11 ` [PATCH 05/10] ublk: make sure ublk uring cmd handling is done in submitter task context Ming Lei
2023-09-18  4:11 ` [PATCH 06/10] ublk: make sure that uring cmd aiming at same queue won't cross io_uring contexts Ming Lei
2023-09-18  4:11 ` [PATCH 07/10] ublk: rename mm_lock as lock Ming Lei
2023-09-18  4:11 ` [PATCH 08/10] ublk: quiesce request queue when aborting queue Ming Lei
2023-09-18  4:11 ` [PATCH 09/10] ublk: replace monitor work with uring_cmd exit notifier Ming Lei
2023-09-18  4:11 ` [PATCH 10/10] ublk: simplify aborting request Ming Lei
2023-09-18 12:54 ` Jens Axboe [this message]
2023-09-18 13:24   ` [PATCH 00/10] io_uring/ublk: exit notifier support Ming Lei
2023-09-18 14:15     ` Jens Axboe
2023-09-18 16:02       ` Ming Lei
2023-09-18 16:03         ` 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] \
    [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