public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
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


  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