All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haggai Eran <haggaie@mellanox.com>
To: Christoph Hellwig <hch@infradead.org>,
	davide rossetti <davide.rossetti@gmail.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Kovalyov Artemy <artemyko@mellanox.com>,
	"dledford@redhat.com" <dledford@redhat.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Leon Romanovsky <leonro@mellanox.com>,
	Sagi Grimberg <sagig@mellanox.com>
Subject: Re: [RFC 0/7] Peer-direct memory
Date: Wed, 17 Feb 2016 17:25:19 +0200	[thread overview]
Message-ID: <56C490DF.1090100@mellanox.com> (raw)
In-Reply-To: <20160217084412.GA13616@infradead.org>

On 17/02/2016 10:44, Christoph Hellwig wrote:
> That doesn't change how the are managed.  We've always suppored mapping
> BARs to userspace in various drivers, and the only real news with things
> like the pmem driver with DAX or some of the things people want to do
> with the NVMe controller memoery buffer is that there are much bigger
> quantities of it, and:
> 
>  a) people want to be able  have cachable mappings of various kinds
>     instead of the old uncachable default.
What if we do want an uncachable mapping for our device's BAR. Can we still 
expose it under ZONE_DEVICE?

>  b) we want to be able to DMA (including RDMA) to the regions in the
>     BARs.
> 
> a) is something that needs smaller amounts in all kinds of areas to be
> done properly, but in principle GPU drivers have been doing this forever
> using all kinds of hacks.
> 
> b) is the real issue.  The Linux DMA support code doesn't really operate
> on just physical addresses, but on page structures, and we don't
> allocate for BARs.  We investigated two ways to address this:  1) allow
> DMA operations without struct page and 2) create struct page structures
> for BARs that we want to be able to use DMA operations on.  For various
> reasons version 2) was favored and this is how we ended up with
> ZONE_DEVICE.  Read the linux-mm and linux-nvdimm lists for the lenghty
> discussions how we ended up here.

I was wondering what are your thoughts regarding the other questions we raised
about ZONE_DEVICE.

How can we overcome the section-alignment requirement in the current code? Our 
HCA's BARs are usually smaller than 128MB.

Sagi also asked how should a peer device who got a ZONE_DEVICE page know it 
should stop using it (the CMB example).

Regards,
Haggai



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-02-17 15:25 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-11 16:12 [RFC 0/7] Peer-direct memory Artemy Kovalyov
     [not found] ` <1455207177-11949-1-git-send-email-artemyko-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2016-02-11 16:12   ` [RFC 1/7] IB/core: Introduce peer client interface Artemy Kovalyov
2016-02-11 16:12   ` [RFC 2/7] IB/core: Get/put peer memory client Artemy Kovalyov
2016-02-11 16:12   ` [RFC 3/7] IB/core: Umem tunneling peer memory APIs Artemy Kovalyov
2016-02-11 16:12   ` [RFC 4/7] IB/core: Infrastructure to manage peer core context Artemy Kovalyov
2016-02-11 16:12   ` [RFC 5/7] IB/core: Invalidation support for peer memory Artemy Kovalyov
2016-02-11 16:12   ` [RFC 6/7] IB/core: Peer memory client for IO memory Artemy Kovalyov
2016-02-11 16:12   ` [RFC 7/7] IB/mlx5: Invalidation support for MR over peer memory Artemy Kovalyov
2016-02-11 19:18   ` [RFC 0/7] Peer-direct memory Jason Gunthorpe
     [not found]     ` <20160211191838.GA23675-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-02-12 20:13       ` Christoph Hellwig
     [not found]         ` <20160212201328.GA14122-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-02-12 20:36           ` Jason Gunthorpe
     [not found]             ` <20160212203649.GA10540-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-02-14 15:25               ` Sagi Grimberg
     [not found]                 ` <56C09C7E.4060808-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-02-18 14:44                   ` Stephen Bates
2016-02-21  9:06                     ` Haggai Eran
     [not found]                       ` <56C97E13.9090101-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2016-02-24 23:45                         ` Stephen Bates
2016-02-24 23:45                           ` Stephen Bates
2016-02-25 11:27                           ` Haggai Eran
2016-02-14 14:09           ` Haggai Eran
2016-02-14 14:05       ` Haggai Eran
2016-02-14 14:27     ` Haggai Eran
2016-02-16 18:22       ` Jason Gunthorpe
2016-02-17  4:03         ` davide rossetti
     [not found]           ` <CAPSaadxbFCOcKV=c3yX7eGw9Wqzn3jvPRZe2LMWYmiQcijT4nw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-17  4:13             ` davide rossetti
2016-02-17  4:13               ` davide rossetti
2016-02-17  4:44               ` Jason Gunthorpe
2016-02-17  8:49                 ` Christoph Hellwig
     [not found]                   ` <20160217084959.GB13616-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-02-18 17:12                     ` Jason Gunthorpe
2016-02-18 17:12                       ` Jason Gunthorpe
     [not found]               ` <CAPSaadx3vNBSxoWuvjrTp2n8_-DVqofttFGZRR+X8zdWwV86nw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-17  8:44                 ` Christoph Hellwig
2016-02-17  8:44                   ` Christoph Hellwig
2016-02-17 15:25                   ` Haggai Eran [this message]
     [not found]                     ` <56C490DF.1090100-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2016-02-19 18:54                       ` Dan Williams
2016-02-19 18:54                         ` Dan Williams

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=56C490DF.1090100@mellanox.com \
    --to=haggaie@mellanox.com \
    --cc=artemyko@mellanox.com \
    --cc=davide.rossetti@gmail.com \
    --cc=dledford@redhat.com \
    --cc=hch@infradead.org \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=leonro@mellanox.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sagig@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 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.