From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
io-uring@vger.kernel.org, axboe@kernel.dk, hch@lst.de,
joshi.k@samsung.com, martin.petersen@oracle.com,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH 2/4] nvme: use bio_integrity_map_user
Date: Thu, 19 Oct 2023 07:40:26 +0200 [thread overview]
Message-ID: <20231019054026.GD14346@lst.de> (raw)
In-Reply-To: <20231018151843.3542335-3-kbusch@meta.com>
On Wed, Oct 18, 2023 at 08:18:41AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> Map user metadata buffers directly instead of maintaining a complicated
> copy buffer.
>
> Now that the bio tracks the metadata through its bip, nvme doesn't need
> special metadata handling, callbacks, or additional fields in the pdu.
> This greatly simplifies passthrough handling and avoids a "might_fault"
> copy_to_user in the completion path. This also creates pdu space to
> track the original request separately from its bio, further simplifying
> polling without relying on special iouring fields.
>
> The downside is that nvme requires the metadata buffer be physically
> contiguous, so user space will need to utilize huge pages if the buffer
> needs to span multiple pages. In practice, metadata payload sizes are a
> small fraction of the main payload, so this shouldn't be a problem.
We can't just remove the old path. We might still need bounce
buffering to due misalignment and/or because it is notcontiguous.
Same as we have a direct map and a copy path for data.
next prev parent reply other threads:[~2023-10-19 5:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 15:18 [PATCH 0/4] block integrity: direclty map user space addresses Keith Busch
2023-10-18 15:18 ` [PATCH 1/4] block: bio-integrity: add support for user buffers Keith Busch
2023-10-19 5:39 ` Christoph Hellwig
2023-10-21 3:53 ` kernel test robot
2023-10-21 4:13 ` kernel test robot
2023-10-25 12:51 ` Kanchan Joshi
2023-10-25 14:42 ` Keith Busch
2023-10-18 15:18 ` [PATCH 2/4] nvme: use bio_integrity_map_user Keith Busch
2023-10-19 5:40 ` Christoph Hellwig [this message]
2023-10-25 13:26 ` Kanchan Joshi
2023-10-18 15:18 ` [PATCH 3/4] iouring: remove IORING_URING_CMD_POLLED Keith Busch
2023-10-19 5:41 ` Christoph Hellwig
2023-10-19 14:43 ` Keith Busch
2023-10-23 6:18 ` Kanchan Joshi
2023-10-18 15:18 ` [PATCH 4/4] io_uring: remove uring_cmd cookie Keith Busch
2023-10-19 5:34 ` [PATCH 0/4] block integrity: direclty map user space addresses Christoph Hellwig
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 \
--in-reply-to=20231019054026.GD14346@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.