On 18/04/17 01:01 PM, Jason Gunthorpe wrote: > Ultimately every dma_ops will need special code to support P2P with > the special hardware that ops is controlling, so it makes some sense > to start by pushing the check down there in the first place. This > advice is partially motivated by how dma_map_sg is just a small > wrapper around the function pointer call... Yes, I noticed this problem too and that makes sense. It just means every dma_ops will probably need to be modified to either support p2p pages or fail on them. Though, the only real difficulty there is that it will be a lot of work. > Where p2p_same_segment_map_page checks if the two devices are on the > 'same switch' and if so returns the address translated to match the > bus address programmed into the BAR or fails. We knows this case is > required to work by the PCI spec, so it makes sense to use it as the > first canned helper. I've also suggested that this check should probably be done (or perhaps duplicated) before we even get to the map stage. In the case of nvme-fabrics we'd probably want to let the user know when they try to configure it or at least fall back to allocating regular memory instead. It would be a difficult situation to have already copied a block of data from a NIC to p2p memory only to have it be deemed unmappable on the NVMe device it's destined for. (Or vice-versa.) This was another issue p2pmem was attempting to solve. 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
