public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Keith Busch <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected]
Cc: [email protected], [email protected],
	[email protected], Keith Busch <[email protected]>
Subject: Re: [PATCHv7 2/6] io_uring: add support for kernel registered bvecs
Date: Wed, 26 Feb 2025 13:36:14 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 2/26/25 11:20 AM, Keith Busch wrote:
> From: Keith Busch <[email protected]>
> 
> Provide an interface for the kernel to leverage the existing
> pre-registered buffers that io_uring provides. User space can reference
> these later to achieve zero-copy IO.
> 
> User space must register an empty fixed buffer table with io_uring in
> order for the kernel to make use of it.

Just a suggestion, but might make sense to not use ->release() as
a gating whether this is a kernel buffer or not, there's room in the
struct anyway with the 'u8 perm' having holes anyway. And if we did
that, then we could just have a default release that does the unpin
and put rather than needing to check and have branches for the two
types of release. Yes the indirect function call isn't free either,
like the branches aren't, but I don't think it matters on the release
side. At least not enough to care, and it'd help streamline the code
a bit and not overload ->release() with meaning "oh this is a kernel
buffer".

-- 
Jens Axboe


  reply	other threads:[~2025-02-26 20:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-26 18:20 [PATCHv7 0/6] ublk zero copy support Keith Busch
2025-02-26 18:20 ` [PATCHv7 1/6] io_uring/rw: move fixed buffer import to issue path Keith Busch
2025-02-26 19:04   ` Jens Axboe
2025-02-26 20:20     ` Jens Axboe
2025-02-27 21:46       ` Keith Busch
2025-02-26 18:20 ` [PATCHv7 2/6] io_uring: add support for kernel registered bvecs Keith Busch
2025-02-26 20:36   ` Jens Axboe [this message]
2025-02-27 15:54   ` Pavel Begunkov
2025-02-27 16:04     ` Jens Axboe
2025-02-27 22:45     ` Keith Busch
2025-02-28 12:19       ` Pavel Begunkov
2025-02-26 18:20 ` [PATCHv7 3/6] nvme: map uring_cmd data even if address is 0 Keith Busch
2025-02-26 18:20 ` [PATCHv7 4/6] ublk: zc register/unregister bvec Keith Busch
2025-02-26 18:40   ` Jens Axboe
2025-02-26 18:21 ` [PATCHv7 5/6] io_uring: add abstraction for buf_table rsrc data Keith Busch
2025-02-26 18:21 ` [PATCHv7 6/6] io_uring: cache nodes and mapped buffers Keith Busch
2025-02-26 18:48   ` Jens Axboe
2025-02-26 19:36   ` Jens Axboe
2025-02-26 19:43     ` Jens Axboe
2025-02-26 19:58       ` Jens Axboe
2025-02-26 20:00         ` Keith Busch

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] \
    /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