On 2019-06-26 2:39 p.m., Dan Williams wrote: > On Wed, Jun 26, 2019 at 1:21 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: >> >> On Wed, Jun 26, 2019 at 12:31:08PM -0600, Logan Gunthorpe wrote: >>>> we have a hole behind len where we could store flag. Preferably >>>> optionally based on a P2P or other magic memory types config >>>> option so that 32-bit systems with 32-bit phys_addr_t actually >>>> benefit from the smaller and better packing structure. >>> >>> That seems sensible. The one thing that's unclear though is how to get >>> the PCI Bus address when appropriate. Can we pass that in instead of the >>> phys_addr with an appropriate flag? Or will we need to pass the actual >>> physical address and then, at the map step, the driver has to some how >>> lookup the PCI device to figure out the bus offset? >> >> I agree with CH, if we go down this path it is a layering violation >> for the thing injecting bio's into the block stack to know what struct >> device they egress&dma map on just to be able to do the dma_map up >> front. >> >> So we must be able to go from this new phys_addr_t&flags to some BAR >> information during dma_map. >> >> For instance we could use a small hash table of the upper phys addr >> bits, or an interval tree, to do the lookup. > > Hmm, that sounds like dev_pagemap without the pages. Yup, that's why I'd like to avoid it, but IMO it would still be an improvement to use a interval tree over struct pages because without struct page we just have a range and a length and it's relatively easy to check that the whole range belongs to a specific pci_dev. To be correct with the struct page approach we really have to loop through all pages to ensure they all belong to the same pci_dev which is a big pain. > There's already no requirement that dev_pagemap point to real / > present pages (DEVICE_PRIVATE) seems a straightforward extension to > use it for helping coordinate phys_addr_t in 'struct bio'. Then > Logan's future plans to let userspace coordinate p2p operations could > build on PTE_DEVMAP. Well I think the biggest difficulty with struct page for user space is dealing with cases when the struct pages of different types get mixed together (or even struct pages that are all P2P pages but from different PCI devices). We'd have to go through each page and ensure that each type gets it's own bio_vec with appropriate flags. Though really, the whole mixed IO from userspace poses a bunch of problems. I'd prefer to just be able to say that a single IO can be all or nothing P2P memory from a single device. Logan
