From: Ming Lei <ming.lei@redhat.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Caleb Sander Mateos <csander@purestorage.com>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
Uday Shankar <ushankar@purestorage.com>
Subject: Re: [PATCH 3/4] ublk: add feature UBLK_F_AUTO_ZERO_COPY
Date: Sun, 27 Apr 2025 15:32:26 +0800 [thread overview]
Message-ID: <aA3dil8q-69jruIq@fedora> (raw)
In-Reply-To: <aA2s3oVFfOF1X485@kbusch-mbp.dhcp.thefacebook.com>
On Sat, Apr 26, 2025 at 10:04:46PM -0600, Keith Busch wrote:
> On Sun, Apr 27, 2025 at 11:10:30AM +0800, Ming Lei wrote:
> > On Sat, Apr 26, 2025 at 08:34:40PM -0600, Keith Busch wrote:
> > >
> > > This is very similiar to something I proposed off-list, and the feedback
> >
> > Looks we both think of it, :-)
>
> Yeah, for real. I was a bit dismayed when I learned of such use cases.
> So much simplicity and elegance went away...
That is reality, and probably these use cases may be addressed elegantly too
in future...
>
> > > back then was this won't work because the back-end ring that wants to
> > > use the zero-copy buffer isn't the same as the ublk server ring
> > > recieving notification of a new command; the ublk driver has no idea
> > > which uring to register the bvec with. Also, this is using the request
> > > "tag" as the io_uring buf index, which wouldn't work when the ublk
> > > server ring handles multiple ublk devices due to the tag collisions.
> > >
> > > If you're can make those trade-offs, then this is a great simplification
> > > to the whole thing.
> >
> > The io_uring fd & buffer index can be provided from 'ublksrv_io_cmd'.
> >
> > https://lore.kernel.org/linux-block/aA2RNG3-WzuQqEN6@fedora/
> >
> > If we only support IORING_ENTER_REGISTERED_RING, 32bit is enough for
> > io_uring fd & buffer index, and there is still 64bits available if not
> > taking UBLK_F_ZONED into account.
>
> We still need a registered sparse table for the backend ring. I think
> maybe a simple ida from the ublk driver to select an index may let the
> daemon register something reasonably small.
Yeah, I think it is reasonable to let userspace register the sparse table,
and we can document it in UAPI.
thanks,
Ming
next prev parent reply other threads:[~2025-04-27 7:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-26 9:41 [PATCH 0/4] ublk: two fixes and support UBLK_F_AUTO_ZERO_COPY Ming Lei
2025-04-26 9:41 ` [PATCH 1/4] selftests: ublk: fix UBLK_F_NEED_GET_DATA Ming Lei
2025-04-26 20:15 ` Caleb Sander Mateos
2025-04-27 1:26 ` Ming Lei
2025-04-26 9:41 ` [PATCH 2/4] ublk: enhance check for register/unregister io buffer command Ming Lei
2025-04-26 20:38 ` Caleb Sander Mateos
2025-04-27 1:37 ` Ming Lei
2025-04-27 3:14 ` Caleb Sander Mateos
2025-04-27 3:49 ` Ming Lei
2025-04-26 9:41 ` [PATCH 3/4] ublk: add feature UBLK_F_AUTO_ZERO_COPY Ming Lei
2025-04-26 22:42 ` Caleb Sander Mateos
2025-04-27 2:06 ` Ming Lei
2025-04-27 3:09 ` Caleb Sander Mateos
2025-04-27 3:15 ` Ming Lei
2025-04-27 2:34 ` Keith Busch
2025-04-27 3:10 ` Ming Lei
2025-04-27 4:04 ` Keith Busch
2025-04-27 7:32 ` Ming Lei [this message]
2025-04-26 9:41 ` [PATCH 4/4] selftests: ublk: support UBLK_F_AUTO_ZERO_COPY Ming Lei
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=aA3dil8q-69jruIq@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=ushankar@purestorage.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.