On Wed, Dec 13, 2023 at 04:36:34PM +0100, Christoph Hellwig wrote: > On Wed, Dec 13, 2023 at 08:31:55AM -0400, Jason Gunthorpe wrote: > > > That is, populate a scatterlist with ubuf->pagecount number of entries, > > > where each segment if of size PAGE_SIZE, in order to be consistent and > > > support a wide variety of DMA importers that may not probably handle > > > segments that are larger than PAGE_SIZE. > > > > No! This is totally wrong, sg lists must aggregate up to the limits > > specified in the struct device. We have importer helpers that do this > > aggregation. > > > > If some driver is working with a sglist and can't handle this it is > > simply broken. Do not mess up core code to accomodate such things. > > Well.. There's no single driver that is broken, it's more the whole > dmabuf philosophy that wants things to be mappable by multiple devices > without knowing their limits beforehand. So you'll get this cargo > culting. It is not so bad, the API has the importer pass a struct device to the exporter that can be used in the usual way to shape the sg list. But really, I think in most cases importers don't strictly need the sg list to be a certain configuration, it is just a combination of lazy driver writers and a lack of common helpers to iterate over the sg list in the way they need. RDMA has done this right, but for it to work efficiently the exporter *must* aggregate all contiguous memory into a single sg element otherwise you loose the HW's large page support. Jason