;Linux-media" ,
> "dri-devel" , "linux-pci"
> , "John Bridgman"
> , "Felix Kuehling" , "Serguei
> Sagalovitch"
> , "Paul Blinzer" ,
> "Christian Koenig" ,
> "Suravee Suthikulpanit" , "Ben Sander&qu
Please don't top post, write shorter lines, and add the odd blank line.
Big blocks of text are hard to read quickly.
> From: Petrosyan, Ludwig [mailto:ludwig.petros...@desy.de]
> Yes I agree it has to be started with the write transaction, according of
> PCIe standard all write
> transaction are
From: Petrosyan Ludwig
> Sent: 22 October 2017 07:14
> Could be I have done is stupid...
> But at first sight it has to be simple:
> The PCIe Write transactions are address routed, so if in the packet header
> the other endpoint address
> is written the TLP has to be routed (by PCIe Switch to the
On 23/10/17 10:08 AM, David Laight wrote:
It is also worth checking that the hardware actually supports p2p transfers.
Writes are more likely to be supported then reads.
ISTR that some intel cpus support some p2p writes, but there could easily
be errata against them.
Ludwig mentioned a PCIe s
;
, "dri-devel" ,
"linux-pci" , "John Bridgman"
, "Felix Kuehling" , "Serguei
Sagalovitch" , "Paul Blinzer"
, "Christian Koenig" , "Suravee
Suthikulpanit" , "Ben Sander"
Sent: Tuesday, 24 October, 2017 00:04:26
On 22/10/17 12:13 AM, Petrosyan, Ludwig wrote:
> But at first sight it has to be simple:
> The PCIe Write transactions are address routed, so if in the packet header
> the other endpoint address is written the TLP has to be routed (by PCIe
> Switch to the endpoint), the DMA reading from the end
Hi Ludwig,
P2P transactions are still *very* experimental at the moment and take a
lot of expertise to get working in a general setup. It will definitely
require changes to the kernel, including the drivers of all the devices
you are trying to make talk to eachother. If you're up for it you ca
ig, Christian"
, "Suthikulpanit, Suravee"
, "Sander, Ben"
Sent: Friday, 20 October, 2017 17:48:58
Subject: Re: Enabling peer to peer device transactions for PCIe devices
Hi Ludwig,
P2P transactions are still *very* experimental at the moment and take a
lot of expertis
Dear Linux kernel group
my name is Ludwig Petrosyan I am working in DESY (Germany)
we are responsible for the control system of all accelerators in DESY.
For a 7-8 years we have switched to MTCA.4 systems and using PCIe as a
central Bus.
I am mostly responsible for the Linux drivers of the
Am 12.01.2017 um 16:11 schrieb Jerome Glisse:
On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote:
On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote:
On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
Make a generic API for all of this and you'd have my vote..
IMHO, you must supp
On 11/01/17 09:54 PM, Stephen Bates wrote:
> The iopmem patchset addressed all the use cases above and while it is not
> an in kernel API it could have been modified to be one reasonably easily.
> As Logan states the driver can then choose to pass the VMAs to user-space
> in a manner that makes s
On Thu, Jan 12, 2017 at 10:11:29AM -0500, Jerome Glisse wrote:
> On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote:
> > > What we want is for RDMA, O_DIRECT, etc to just work with special VMAs
> > > (ie. at least those backed with ZONE_DEVICE memory). Then
> > > GPU/NVME/DAX/whatever dr
On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote:
> On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote:
> >
> >
> > On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
> >
> >
> >> Make a generic API for all of this and you'd have my vote..
> >>
> >>
> >> IMHO, you must support basic pinn
On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote:
>
>
> On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
>
>
>> Make a generic API for all of this and you'd have my vote..
>>
>>
>> IMHO, you must support basic pinning semantics - that is necessary to
>> support generic short lived DMA (eg filesys
14 matches
Mail list logo
