public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: "Bhatia, Sumeet" <[email protected]>,
	"[email protected]" <[email protected]>
Cc: "Hegde, Pramod" <[email protected]>, Jens Axboe <[email protected]>
Subject: Re: Non sequential linked chains and IO_LINK support
Date: Thu, 7 May 2020 01:11:46 +0300	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 07/05/2020 00:46, Bhatia, Sumeet wrote:
> Hello everyone,
> 
> I've been exploring iouring to submit disk operations. My application generates disk operations based on some events and operations are unknown until those events occur.  Some of these disk operations are interdependent others are not. 
> 
> Example: Following operations are generated and submitted before any of them are complete
> operation_0 (independent operation)
> operation_1 (independent operation),​
> operation_2 (to be issued only if operation_0 was successful),
> operation_3 (independent operation),
> operation_4 (to be issued only if operation_1 was successful)
> 
> In my example I have two independent link chains, (operation_0, operation_2) and (operation_1, operation_4).  iouring documentation suggests IOSQE_IO_LINK expects link chains to be sequential and will not support my use case. 

First of all, there shouldn't be a submission (i.e. io_uring_enter(to_submit>0))
between adding linked requests to a submission queue (SQ). It'd be racy otherwise.

E.g. you can't do:

add_sqe(op0)
submit(op0)
add_sqe(op2, linked)

Though the following is valid, as we don't submit op0:

add_sqe(opX)
add_sqe(op0)
submit(up until opX)
add_sqe(op2, linked)


And that means you can reorder them just before submitting, or filing them into
the SQ in a better order.

Is it helpful? Let's figure out how to cover your case.


> I explored creating new iouring context for each of these linked chains. But it turns out depending on disk size there can be somewhere between 500-1000 such chains. I'm not sure whether it is prudent to create that many iouring contexts.

Then you would need to wait on them (e.g. epoll or 1000 threads), and that would
defeat the whole idea. In any case even with sharing io-wq and having small CQ
and SQ, it'd be wasteful keeping many resources duplicated.

> 
> I am reaching out to check whether there would be a generic need to support nonsequential linked chains on a single iouring context. Would love to hear all your thoughts.
> 
> Thanks,
> Sumeet
> 

-- 
Pavel Begunkov

  reply	other threads:[~2020-05-06 22:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 21:46 Non sequential linked chains and IO_LINK support Bhatia, Sumeet
2020-05-06 22:11 ` Pavel Begunkov [this message]
2020-05-07  1:04   ` Bhatia, Sumeet
2020-05-07  8:39     ` Pavel Begunkov

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