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 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.