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 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
