public inbox for [email protected]
 help / color / mirror / Atom feed
From: Breno Leitao <[email protected]>
To: Keith Busch <[email protected]>
Cc: [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected]
Subject: Re: [PATCH 0/5] add initial io_uring_cmd support for sockets
Date: Thu, 6 Apr 2023 09:58:40 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <ZC72UKx/[email protected]>

Hello Keith,

On Thu, Apr 06, 2023 at 10:41:52AM -0600, Keith Busch wrote:
> On Thu, Apr 06, 2023 at 07:43:26AM -0700, Breno Leitao wrote:
> > This patchset creates the initial plumbing for a io_uring command for
> > sockets.
> > 
> > For now, create two uring commands for sockets, SOCKET_URING_OP_SIOCOUTQ
> > and SOCKET_URING_OP_SIOCINQ. They are similar to ioctl operations
> > SIOCOUTQ and SIOCINQ. In fact, the code on the protocol side itself is
> > heavily based on the ioctl operations.
> 
> Do you have asynchronous operations in mind for a future patch? The io_uring
> command infrastructure makes more sense for operations that return EIOCBQUEUED,
> otherwise it doesn't have much benefit over ioctl.

I think this brings value even for synchronos operations, such as, you
can just keep using io_uring operations on network operations, other
than, using some io_uring operations and then doing a regular ioctl(2).
So, it improves the user experience.

The other benefit is calling several operations at a single io_uring
submit. It means you can save several syscalls and getting the same work
done.

>  
> > In order to test this code, I created a liburing test, which is
> > currently located at [1], and I will create a pull request once we are
> > good with this patch.
> > 
> > I've also run test/io_uring_passthrough to make sure the first patch
> > didn't regressed the NVME passthrough path.
> > 
> > This patchset is a RFC for two different reasons:
> >   * It changes slighlty on how IO uring command operates. I.e, we are
> >     now passing the whole SQE to the io_uring_cmd callback (instead of
> >     an opaque buffer). This seems to be more palatable instead of
> >     creating some custom structure just to fit small parameters, as in
> >     SOCKET_URING_OP_SIOC{IN,OUT}Q. Is this OK?
> 
> I think I'm missing something from this series. Where is the io_uring_cmd
> change to point to the sqe?

My bad, the patch was not part of the patchset. I've just submitted it
under the same RFC cover letter now.

Here is the link, if it helps:

https://lkml.org/lkml/2023/4/6/990



  parent reply	other threads:[~2023-04-06 16:58 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 14:43 [PATCH 0/5] add initial io_uring_cmd support for sockets Breno Leitao
2023-04-06 14:43 ` [RFC PATCH 1/4] net: wire up support for file_operations->uring_cmd() Breno Leitao
2023-04-06 14:43 ` [RFC PATCH 2/4] net: add uring_cmd callback to UDP Breno Leitao
2023-04-11 12:54   ` Pavel Begunkov
2023-04-06 14:43 ` [RFC PATCH 3/4] net: add uring_cmd callback to TCP Breno Leitao
2023-04-06 14:43 ` [RFC PATCH 4/4] net: add uring_cmd callback to raw "protocol" Breno Leitao
2023-04-06 15:34 ` [PATCH 0/5] add initial io_uring_cmd support for sockets Willem de Bruijn
2023-04-06 15:59   ` Breno Leitao
2023-04-06 18:16     ` Willem de Bruijn
2023-04-07  2:46       ` David Ahern
2023-04-11 12:00         ` Breno Leitao
2023-04-11 14:36           ` David Ahern
2023-04-11 14:41             ` Jens Axboe
2023-04-11 14:51               ` Willem de Bruijn
2023-04-11 14:54                 ` Jens Axboe
2023-04-11 15:00                   ` Willem de Bruijn
2023-04-11 15:06                     ` Jens Axboe
2023-04-11 15:24                       ` Willem de Bruijn
2023-04-11 15:28                         ` Jens Axboe
2023-04-12 13:53                           ` Breno Leitao
2023-04-12 14:28                             ` Willem de Bruijn
2023-04-13  0:02                               ` Breno Leitao
2023-04-13 14:24                                 ` Willem de Bruijn
2023-04-13 14:45                                   ` Jakub Kicinski
2023-04-13 14:57                                   ` David Laight
2023-04-18 13:23                                   ` Breno Leitao
2023-04-18 19:41                                     ` Willem de Bruijn
2023-04-20 14:43                                       ` Breno Leitao
2023-04-20 16:48                                         ` Willem de Bruijn
2023-04-11 15:10               ` David Ahern
2023-04-11 15:17                 ` Jens Axboe
2023-04-11 15:27                   ` David Ahern
2023-04-11 15:29                     ` Jens Axboe
2023-04-12  7:39                     ` David Laight
2023-04-06 16:41 ` Keith Busch
2023-04-06 16:49   ` Jens Axboe
2023-04-06 16:58   ` Breno Leitao [this message]
2023-04-06 16:57 ` [PATCH RFC] io_uring: Pass whole sqe to commands Breno Leitao
2023-04-07 18:51   ` Keith Busch
2023-04-11 12:22     ` Breno Leitao
2023-04-11 12:39       ` Pavel Begunkov
2023-04-13  2:56   ` Ming Lei
2023-04-13 16:47     ` Breno Leitao
2023-04-14  2:12       ` Ming Lei
2023-04-14 13:12         ` Pavel Begunkov
2023-04-14 13:59           ` Ming Lei
2023-04-14 14:56             ` Pavel Begunkov
2023-04-16  9:51               ` Ming Lei
  -- strict thread matches above, loose matches on Subject: below --
2023-05-02  9:21 [PATCH 0/5] add initial io_uring_cmd support for sockets Adrien Delorme
2023-05-02 13:03 ` Pavel Begunkov
2023-05-03 13:11   ` Adrien Delorme
2023-05-03 13:27     ` David Laight

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] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [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