From: Ming Lei <ming.lei@redhat.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: linux-block@vger.kernel.org, lsf-pc@lists.linux-foundation.org,
"Liu Xiaodong" <xiaodong.liu@intel.com>,
"Jim Harris" <james.r.harris@intel.com>,
"Hans Holmberg" <Hans.Holmberg@wdc.com>,
"Matias Bjørling" <Matias.Bjorling@wdc.com>,
"hch@lst.de" <hch@lst.de>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
ZiyangZhang <ZiyangZhang@linux.alibaba.com>,
ming.lei@redhat.com
Subject: Re: [LSF/MM/BPF BoF]: extend UBLK to cover real storage hardware
Date: Wed, 8 Feb 2023 09:38:42 +0800 [thread overview]
Message-ID: <Y+L9Ijb5Kc3Yow5Z@T590> (raw)
In-Reply-To: <80aa92bc-f9b3-f76e-4e3a-76d3753717d2@acm.org>
On Mon, Feb 06, 2023 at 10:26:55AM -0800, Bart Van Assche wrote:
> On 2/6/23 07:00, Ming Lei wrote:
> > 4) DMA
> > - DMA requires physical memory address, UBLK driver actually has
> > block request pages, so can we export request SG list(each segment
> > physical address, offset, len) into userspace? If the max_segments
> > limit is not too big(<=64), the needed buffer for holding SG list
> > can be small enough.
> >
> > - small amount of physical memory for using as DMA descriptor can be
> > pre-allocated from userspace, and ask kernel to pin pages, then still
> > return physical address to userspace for programming DMA
> >
> > - this way is still zero copy
>
> Would it be possible to use vfio in such a way that zero-copy
> functionality is achieved? I'm concerned about the code duplication that
> would result if a new interface similar to vfio is introduced.
Here I meant we can export physical address of request sg from
/dev/ublkb* to userspace, which can program the DMA controller
using exported physical address. With this way, the userspace driver
can submit IO without entering kernel, then with high performance.
This should how SPDK/nvme-pci[1] is implemented, but SPDK allocates
hugepage for getting its physical address.
[1] https://spdk.io/doc/memory.html
Thanks,
Ming
next prev parent reply other threads:[~2023-02-08 1:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 15:00 [LSF/MM/BPF BoF]: extend UBLK to cover real storage hardware Ming Lei
2023-02-06 17:53 ` Hannes Reinecke
2023-03-08 8:50 ` Hans Holmberg
2023-03-08 12:27 ` Ming Lei
2023-02-06 18:26 ` Bart Van Assche
2023-02-08 1:38 ` Ming Lei [this message]
2023-02-08 18:02 ` Bart Van Assche
2023-02-06 20:27 ` Stefan Hajnoczi
2023-02-08 2:12 ` Ming Lei
2023-02-08 12:17 ` Stefan Hajnoczi
2023-02-13 3:47 ` Ming Lei
2023-02-13 19:13 ` Stefan Hajnoczi
2023-02-15 0:51 ` Ming Lei
2023-02-15 15:27 ` Stefan Hajnoczi
2023-02-16 0:46 ` Ming Lei
2023-02-16 15:28 ` Stefan Hajnoczi
2023-02-16 9:44 ` Andreas Hindborg
2023-02-16 10:45 ` Ming Lei
2023-02-16 11:21 ` Andreas Hindborg
2023-02-17 2:20 ` Ming Lei
2023-02-17 16:39 ` Stefan Hajnoczi
2023-02-18 11:22 ` Ming Lei
2023-02-18 18:38 ` Stefan Hajnoczi
2023-02-22 23:17 ` Ming Lei
2023-02-23 20:18 ` Stefan Hajnoczi
2023-03-02 3:22 ` Ming Lei
2023-03-02 15:09 ` Stefan Hajnoczi
2023-03-17 3:10 ` Ming Lei
2023-03-17 14:41 ` Stefan Hajnoczi
2023-03-18 0:30 ` Ming Lei
2023-03-20 12:34 ` Stefan Hajnoczi
2023-03-20 15:30 ` Ming Lei
2023-03-21 11:25 ` Stefan Hajnoczi
2023-03-16 14:24 ` Stefan Hajnoczi
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=Y+L9Ijb5Kc3Yow5Z@T590 \
--to=ming.lei@redhat.com \
--cc=Hans.Holmberg@wdc.com \
--cc=Matias.Bjorling@wdc.com \
--cc=ZiyangZhang@linux.alibaba.com \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=james.r.harris@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=stefanha@redhat.com \
--cc=xiaodong.liu@intel.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