lkml.org 
[lkml]   [2017]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory


    On 17/04/17 11:04 AM, Dan Williams wrote:
    >> Yes, in this scheme, it needs an additional p2pmem child. Why is that an
    >> issue? It certainly makes it a lot easier for the user to understand the
    >> p2pmem memory in the system (through the sysfs tree) and reason about
    >> the topology and when to use it. This is important.
    >
    > I think you want to go the other way in the hierarchy and find a
    > shared *parent* to land the p2pmem capability. Because that same agent
    > is going to be responsible handling address translation for the peers.
    >
    > Peer-dma is always going to be a property of the bus and not the end
    > devices. Requiring each bus implementation to explicitly enable
    > peer-to-peer support is a feature not a bug.
    >
    > We shouldn't design for some future possible use case. Solve it for
    > pci and when / if another bus comes along then look at a more generic
    > abstraction.

    Thanks Dan, these are some good points. Wedding it closer to the PCI
    code makes more sense to me now. I'd still think you'd want some struct
    device though to appear in the device hierarchy and allow reasoning
    about topology.

    Logan

    \
     
     \ /
      Last update: 2017-04-18 07:23    [W:2.667 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site