On Fri, Jun 28, 2019 at 12:29:32PM -0600, Logan Gunthorpe wrote: > > > On 2019-06-28 11:29 a.m., Jason Gunthorpe wrote: > > On Fri, Jun 28, 2019 at 10:22:06AM -0600, Logan Gunthorpe wrote: > > > >>> Why not? If we have a 'bar info' structure that could have data > >>> transfer op callbacks, infact, I think we might already have similar > >>> callbacks for migrating to/from DEVICE_PRIVATE memory with DMA.. > >> > >> Well it could, in theory be done, but It just seems wrong to setup and > >> wait for more DMA requests while we are in mid-progress setting up > >> another DMA request. Especially when the block layer has historically > >> had issues with stack sizes. It's also possible you might have multiple > >> bio_vec's that have to each do a migration and with a hook here they'd > >> have to be done serially. > > > > *shrug* this is just standard bounce buffering stuff... > > I don't know of any "standard" bounce buffering stuff that uses random > other device's DMA engines where appropriate. IMHO, it is conceptually the same as memcpy.. And probably we will not ever need such optimization in dma map. Other copy places might be different at least we have the option. > IMO the bouncing in the DMA layer isn't a desirable thing, it was a > necessary addition to work around various legacy platform issues and > have existing code still work correctly. Of course it is not desireable! But there are many situations where we do not have the luxury to work around the HW limits in the caller, so those callers either have to not do DMA or they have to open code bounce buffering - both are wrong. > > What I see as the question is how to layout the BIO. > > > > If we agree the bio should only have phys_addr_t then we need some > > 'bar info' (ie at least the offset) in the dma map and some 'bar info' > > (ie the DMA device) during the bio construciton. > > Per my other email, it was phys_addr_t plus hints on how to map the > memory (bus address, dma_map_resource, or regular). This requires > exactly two flag bits in the bio_vec and no interval tree or hash table. > I don't want to have to pass bar info, other hooks, or anything like > that to the block layer. This scheme makes the assumption that the dma mapping struct device is all you need, and we never need to know the originating struct device during dma map. This is clearly safe if the two devices are on the same PCIe segment However, I'd feel more comfortable about that assumption if we had code to support the IOMMU case, and know for sure it doesn't require more info :( But I suppose it is also reasonable that only the IOMMU case would have the expensive 'bar info' lookup or something. Maybe you can hide these flags as some dma_map helper, then the layering might be nicer: dma_map_set_bio_p2p_flags(bio, phys_addr, source dev, dest_dev) ? ie the choice of flag scheme to use is opaque to the DMA layer. > > If we can spare 4-8 bits in the bio then I suggest a 'perfect hash > > table'. Assign each registered P2P 'bar info' a small 4 bit id and > > hash on that. It should be fast enough to not worry about the double > > lookup. > > This feels like it's just setting us up to run into nasty limits based > on the number of bits we actually have. The number of bits in a bio_vec > will always be a precious resource. If I have a server chassis that > exist today with 24 NVMe devices, and each device has a CMB, I'm already > using up 6 of those bits. Then we might have DEVICE_PRIVATE and other > uses on top of that. A hash is an alternative data structure to a interval tree that has better scaling for small numbers of BARs, which I think is our case. Jason
