From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
kbusch@kernel.org, axboe@kernel.dk, linux-block@vger.kernel.org,
martin.petersen@oracle.com, anuj20.g@samsung.com
Subject: Re: [PATCH] block: streamline meta bounce buffer handling
Date: Mon, 6 May 2024 16:56:09 +0200 [thread overview]
Message-ID: <20240506145609.GA11066@lst.de> (raw)
In-Reply-To: <9ce1c36d-67e5-b287-5faf-667844f8c2a8@samsung.com>
On Mon, May 06, 2024 at 06:16:45PM +0530, Kanchan Joshi wrote:
> Nvme and io_uring (Patch 2, 3, 4) get nice wins because of keeping the
> user memory pinned even for bounce-buffer case.
In that case the data path should be doing the same.
> > Sort of related to that is that this does driver the copy to user and
> > unpin from bio_integrity_free, which is a low-level routine. It really
> > should be driven from the highlevel blk-map code that is the I/O
> > submitter, just like the data side. Shoe-horning uaccess into the
> > low-level block layer plumbing is just going to get us into trouble.
> >
>
> Not sure I follow, but citing this nvme patch again:
> https://lore.kernel.org/linux-block/20231130215309.2923568-3-kbusch@meta.com/
> Driver does not need to know whether meta was handled by pinning or by
> using bounce buffer. Everything is centrally handled in
> block/bio-integrity.c.
But the low-level bio code does, and it absolutely should not. And
while I should have caught this earlier we really need to stop undoing
all the sanity we got by clearly splitting the submitter side from
the consumer side of the bio, as that will lead us straight back
into the mess we had before.
next prev parent reply other threads:[~2024-05-06 14:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240506051751epcas5p1ed84e21495e12c7bf41e94827aa85e33@epcas5p1.samsung.com>
2024-05-06 5:10 ` [PATCH] block: streamline meta bounce buffer handling Kanchan Joshi
2024-05-06 6:05 ` Christoph Hellwig
2024-05-06 12:46 ` Kanchan Joshi
2024-05-06 14:56 ` Christoph Hellwig [this message]
2024-05-06 20:36 ` Keith Busch
2024-05-07 5:45 ` Christoph Hellwig
2024-05-24 10:28 ` Kanchan Joshi
2024-05-28 7:59 ` 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=20240506145609.GA11066@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).