public inbox for [email protected]
 help / color / mirror / Atom feed
From: Mark Papadakis <[email protected]>
To: io-uring <[email protected]>
Subject: Extending the functionality of some SQE OPs
Date: Tue, 21 Jan 2020 09:50:54 +0200	[thread overview]
Message-ID: <[email protected]> (raw)

Would it make sense to extend the semantics of some OPS of specific syscalls to, for example, return in the CQE more than just an int (matching the semantics of the specific syscall they represent)?
For example, the respective OP for accept/accept4 returns an int for error or the fd of the accepted connection’s socket FD. But, given the clean-room implementation of io_uring, this may be a good opportunity to expand on it. Maybe there should be another field in the CQEs e.g
union {
	int i32;
	uint64_t u64;
	// whatever makes sense
} ret_ex;
Where the implementation of some OPs would access and set accordingly. For example, the OP for accept could set ret_ex.i32 to 1 if there are more outstanding FDs to be dequeued from the accepted connections queue, so that the application should accept again thereby draining it - as opposed to being woken up multiple times to do so. Other OPs may take advantage of this for other reasons.

Maybe it doesn’t make as much sense as I think it does, but if anything, it could become very useful down the road, once more syscalls(even OPs that are entirely new are not otherwise represent existing syscalls?) are implemented(invented?). 

@markpapadakis


             reply	other threads:[~2020-01-21  7:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21  7:50 Mark Papadakis [this message]
2020-01-21 19:55 ` Extending the functionality of some SQE OPs Jens Axboe
2020-01-21 20:54   ` Mark Papadakis
2020-01-21 20:55     ` 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] \
    /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