From: "hch@infradead.org" <hch@infradead.org>
To: Haggai Eran <haggaie@mellanox.com>
Cc: "hch@infradead.org" <hch@infradead.org>,
Liran Liss <liranl@mellanox.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Yishai Hadas <yishaih@mellanox.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"stephen.bates@microsemi.com" <stephen.bates@microsemi.com>,
Leon Romanovsky <leonro@mellanox.com>,
Kovalyov Artemy <artemyko@mellanox.com>,
"j.glisse@gmail.com" <j.glisse@gmail.com>
Subject: Re: [RFC 7/7] NVMe: CMB on DMA-BUF
Date: Thu, 4 Aug 2016 04:56:24 -0700 [thread overview]
Message-ID: <20160804115624.GA12004@infradead.org> (raw)
In-Reply-To: <1470121814.20129.8.camel@mellanox.com>
On Tue, Aug 02, 2016 at 07:10:14AM +0000, Haggai Eran wrote:
> The reason I thought this idea might work is because of the responses
> Stephen got for his attempt to use ZONE_DEVICE for things like the CMB.
> The problem with that is that the way RDMA registration works with
> get_user_pages means that the CPU also gets access to the CMB and
> sometimes you don't want that. DMA-BUF can solve that nicely in that it
> doesn't require mapping it to the CPU - a driver can attach to it
> directly.
I'm not complaining about DMA-BUF - that might be a useful low-level
abstraction if we define a higher level API around it.
> Anyway, I understand exposing the CMB directly might be a little too
> low level. What do you think would work better? Something like
> direct_access that returns bus addresses instead of pfns?
This would be my primary choicse. We'll really need to built an
in-kernel framework for a) PCI P2P access involving drivers for the PCI
switches etc, and then on top of that build something speicifly for
block drivers. Which will be a bit complicated because both have the
case of directly memory mapped device as well as indirect devices like
the CMB. I'm pretty sure we won't get it right at the first attempt,
so exposing it to userspace is an absolute no-go as that will lock us
into the first ABI forever.
next prev parent reply other threads:[~2016-08-04 11:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-01 6:57 [RFC 0/7] RDMA subsystem DMA-BUF support Haggai Eran
2016-08-01 6:57 ` [RFC 1/7] IB/mlx5: Helper for posting work-requests on the UMR QP Haggai Eran
2016-08-01 6:57 ` [RFC 2/7] IB/mlx5: Support registration and invalidate operations " Haggai Eran
2016-08-01 6:57 ` [RFC 3/7] IB/core: Helpers for mapping DMA-BUF in MRs Haggai Eran
2016-08-01 6:57 ` [RFC 4/7] IB/uverbs: Add command to register a DMA-BUF fd Haggai Eran
2016-08-01 6:57 ` [RFC 5/7] IB/mlx5: Implement reg_user_dma_buf_mr Haggai Eran
2016-08-01 6:57 ` [RFC 6/7] NVMe: Use genalloc to allocate CMB regions Haggai Eran
[not found] ` <20160801155348.GB23224@infradead.org>
2016-08-01 16:20 ` Jon Derrick
2016-08-02 7:15 ` Haggai Eran
2016-08-02 6:48 ` Haggai Eran
2016-08-01 6:57 ` [RFC 7/7] NVMe: CMB on DMA-BUF Haggai Eran
2016-08-01 15:52 ` Christoph Hellwig
2016-08-02 7:10 ` Haggai Eran
2016-08-04 11:56 ` hch [this message]
2016-08-07 5:24 ` Haggai Eran
2016-08-03 10:02 ` Sagi Grimberg
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=20160804115624.GA12004@infradead.org \
--to=hch@infradead.org \
--cc=artemyko@mellanox.com \
--cc=haggaie@mellanox.com \
--cc=j.glisse@gmail.com \
--cc=leonro@mellanox.com \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=liranl@mellanox.com \
--cc=stephen.bates@microsemi.com \
--cc=yishaih@mellanox.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).