On Wed, Jun 26, 2019 at 03:18:07PM -0600, Logan Gunthorpe wrote: > > I don't think we should make drives do that. What if it got CMB memory > > on some other device? > > Huh? A driver submitting P2P requests finds appropriate memory to use > based on the DMA device that will be doing the mapping. It *has* to. It > doesn't necessarily have control over which P2P provider it might find > (ie. it may get CMB memory from a random NVMe device), but it easily > knows the NVMe device it got the CMB memory for. Look at the existing > code in the nvme target. No, this all thinking about things from the CMB perspective. With CMB you don't care about the BAR location because it is just a temporary buffer. That is a unique use model. Every other case has data residing in BAR memory that can really only reside in that one place (ie on a GPU/FPGA DRAM or something). When an IO against that is run it should succeed, even if that means bounce buffering the IO - as the user has really asked for this transfer to happen. We certainly don't get to generally pick where the data resides before starting the IO, that luxury is only for CMB. > > I think with some simple caching this will become negligible for cases > > you care about > > Well *maybe* it will be negligible performance wise, but it's also a lot > more complicated, code wise. Tree lookups will always be a lot more > expensive than just checking a flag. Interval trees are pretty simple API wise, and if we only populate them with P2P providers you probably find the tree depth is negligible in current systems with one or two P2P providers. Jason
