On Thu, Apr 08, 2021 at 11:01:12AM -0600, Logan Gunthorpe wrote: > dma_map_sg() either returns a positive number indicating the number > of entries mapped or zero indicating that resources were not available > to create the mapping. When zero is returned, it is always safe to retry > the mapping later once resources have been freed. > > Once P2PDMA pages are mixed into the SGL there may be pages that may > never be successfully mapped with a given device because that device may > not actually be able to access those pages. Thus, multiple error > conditions will need to be distinguished to determine weather a retry > is safe. > > Introduce dma_map_sg_p2pdma[_attrs]() with a different calling > convention from dma_map_sg(). The function will return a positive > integer on success or a negative errno on failure. > > ENOMEM will be used to indicate a resource failure and EREMOTEIO to > indicate that a P2PDMA page is not mappable. > > The __DMA_ATTR_PCI_P2PDMA attribute is introduced to inform the lower > level implementations that P2PDMA pages are allowed and to warn if a > caller introduces them into the regular dma_map_sg() interface. So this new API is all about being able to return an error code because auditing the old API is basically terrifying? OK, but why name everything new P2PDMA? It seems nicer to give this some generic name and have some general program to gradually deprecate normal non-error-capable dma_map_sg() ? I think that will raise less questions when subsystem people see the changes, as I was wondering why RW was being moved to use what looked like a p2pdma only API. dma_map_sg_or_err() would have been clearer The flag is also clearer as to the purpose if it is named __DMA_ATTR_ERROR_ALLOWED Jason
