Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1530501 > unrolled thread

Re: Enabling peer to peer device transactions for PCIe devices

Started byJason Gunthorpe <jgunthorpe@obsidianresearch.com>
First post2016-11-25 20:40 +0100
Last post2016-11-26 00:50 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Enabling peer to peer device transactions for PCIe devices Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2016-11-25 20:40 +0100
    Re: Enabling peer to peer device transactions for PCIe devices Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2016-11-25 21:30 +0100
    Re: Enabling peer to peer device transactions for PCIe devices Alex Deucher <alexdeucher@gmail.com> - 2016-11-26 00:50 +0100

#1530501 — Re: Enabling peer to peer device transactions for PCIe devices

FromJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date2016-11-25 20:40 +0100
SubjectRe: Enabling peer to peer device transactions for PCIe devices
Message-ID<sHuvL-4HW-5@gated-at.bofh.it>
On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:

> b) Allocation may not  have CPU address  at all - only GPU one.

But you don't expect RDMA to work in the case, right?

GPU people need to stop doing this windowed memory stuff :)

Jason

[toc] | [next] | [standalone]


#1530518

FromJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Date2016-11-25 21:30 +0100
Message-ID<sHvi9-5he-1@gated-at.bofh.it>
In reply to#1530501
On Fri, Nov 25, 2016 at 02:49:50PM -0500, Serguei Sagalovitch wrote:

> GPU could perfectly access all VRAM.  It is only issue for p2p without
> special interconnect and CPU access. Strictly speaking as long as we
> have "bus address"  we could have RDMA but  I agreed that for
> RDMA we could/should(?) always "request"  CPU address (I hope that we
> could forget about 32-bit application :-)).

At least on x86 if you have a bus address you have a CPU address. All
RDMAable VRAM has to be visible in the BAR.

> BTW/FYI: About CPU access: Some user-level API is mainly handle based
> so there is no need for CPU access by default.

You mean no need for the memory to be virtually mapped into the
process?

Do you expect to RDMA from this kind of API? How will that work?

Jason

[toc] | [prev] | [next] | [standalone]


#1530573

FromAlex Deucher <alexdeucher@gmail.com>
Date2016-11-26 00:50 +0100
Message-ID<sHypH-7cW-3@gated-at.bofh.it>
In reply to#1530501
On Fri, Nov 25, 2016 at 2:34 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:
>
>> b) Allocation may not  have CPU address  at all - only GPU one.
>
> But you don't expect RDMA to work in the case, right?
>
> GPU people need to stop doing this windowed memory stuff :)
>

Blame 32 bit systems and GPUs with tons of vram :)

I think resizable bars are finally coming in a useful way so this
should go away soon.

Alex

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web