public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: "J.L. Burr" <jlburr-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 00/10] IB: Replace safe uses for ib_get_dma_mr with pd->local_dma_lkey
Date: Tue, 28 Jul 2015 19:56:47 -0400	[thread overview]
Message-ID: <mp94tm$nca$1@ger.gmane.org> (raw)
In-Reply-To: 20150728221050.GA1279@obsidianresearch.com

"Jason Gunthorpe" 
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote in 
message news:20150728221050.GA1279-ePGOBjL8dl3ta4EC/59zMK2raWmgRF17@public.gmane.org

> On Tue, Jul 28, 2015 at 04:58:29PM -0400, J.L. Burr wrote:
>
>> Is there some way now (in upstream kernels) to create a MR with an
>> arbitrary (and large) physical address range?  That would be great! 
>> I
>> didn't see a way to do that when I started on this journey (about 4
>> years ago).
>
> The FRWR API can do this, but it depends on each card if it can manage
> the page list table or not.
>
> You'd need to check page_size_cap and max_map_per_fmr for your card to
> see.
>
> Basically use an array of the largest page size your adaptor will
> support.
>
> Eg mlx5 supports any page size above 4k, so you can do any PCI BAR
> with a single FRWR page table entry.
>
> mlx4 seems to top out at 2G pages (which may just be the driver being
> silly) so you'd need 64k page entries, no idea if it can do that or
> not..

Well, the beauty of the scheme I'm using now is there are no paging 
aspects at all, just a flat 64-bit *physical* address space usable with 
the MR returned from ib_get_dma_mr.

Again, all of the targeted memory spaces are in PCIe BAR space on 
physical devices.  So, no paging, page tables, or pinning, etc.  It's 
always there (well, hardware-willing)!  As the local CPU cannot access 
this space (too big to map), it can only be accessed remotely via RDMA 
requests.

I realize this is a bit unusual.  So, that's why I'm OK for tainting as 
long as I have a way to opt-in to maintain the current ib_get_dma_mr 
scheme.  I understand that this would not be desirable for a normal 
environment.

John 



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2015-07-28 23:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 23:34 [PATCH 00/10] IB: Replace safe uses for ib_get_dma_mr with pd->local_dma_lkey Jason Gunthorpe
2015-07-22 23:34 ` [PATCH 01/10] IB/core: Guarantee that a local_dma_lkey is available Jason Gunthorpe
2015-07-23 10:47   ` Sagi Grimberg
2015-07-23 18:36     ` Jason Gunthorpe
2015-07-22 23:34 ` [PATCH 04/10] IB/mlx4: Remove ib_get_dma_mr calls Jason Gunthorpe
2015-07-22 23:34 ` [PATCH 05/10] IB/mlx5: " Jason Gunthorpe
2015-07-22 23:34 ` [PATCH 06/10] IB/iser: Use pd->local_dma_lkey Jason Gunthorpe
2015-07-23 10:49   ` Sagi Grimberg
     [not found] ` <1437608083-22898-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-07-22 23:34   ` [PATCH 02/10] IB/mad: Remove ib_get_dma_mr calls Jason Gunthorpe
2015-07-22 23:34   ` [PATCH 03/10] IB/ipoib: " Jason Gunthorpe
2015-07-22 23:34   ` [PATCH 07/10] iser-target: " Jason Gunthorpe
2015-07-23 10:49     ` Sagi Grimberg
2015-07-22 23:34   ` [PATCH 08/10] IB/srp: Use pd->local_dma_lkey Jason Gunthorpe
     [not found]     ` <1437608083-22898-9-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-07-23 10:50       ` Sagi Grimberg
2015-07-22 23:34 ` [PATCH 09/10] ib_srpt: Remove ib_get_dma_mr calls Jason Gunthorpe
2015-07-23 10:51   ` Sagi Grimberg
2015-07-22 23:34 ` [PATCH 10/10] net/9p: " Jason Gunthorpe
2015-07-23  7:46   ` Dominique Martinet
2015-07-23 10:56 ` [PATCH 00/10] IB: Replace safe uses for ib_get_dma_mr with pd->local_dma_lkey Sagi Grimberg
2015-07-23 13:47 ` Bart Van Assche
2015-07-23 18:30   ` Jason Gunthorpe
     [not found]     ` <20150723183044.GA1868-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-07-23 18:42       ` Bart Van Assche
     [not found]         ` <55B13583.5010208-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2015-07-23 18:47           ` Jason Gunthorpe
2015-07-26  8:45             ` Sagi Grimberg
2015-07-29 16:39             ` Doug Ledford
2015-07-25  6:27   ` Christoph Hellwig
2015-07-28 15:01 ` J.L. Burr
2015-07-28 18:23   ` Jason Gunthorpe
2015-07-28 20:58     ` J.L. Burr
2015-07-28 22:10       ` Jason Gunthorpe
2015-07-28 23:56         ` J.L. Burr [this message]

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='mp94tm$nca$1@ger.gmane.org' \
    --to=jlburr-vna1kif7wgpbdgjk7y7tuq@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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