On Mon, Apr 11, 2016 at 11:41:57PM +0200, Jesper Dangaard Brouer wrote: > > On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg <s...@grimberg.me> wrote: > > > >> This is also very interesting for storage targets, which face the same > > >> issue. SCST has a mode where it caches some fully constructed SGLs, > > >> which is probably very similar to what NICs want to do. > > > > > > I think a cached allocator for page sets + the scatterlists that > > > describe these page sets would not only be useful for SCSI target > > > implementations but also for the Linux SCSI initiator. Today the scsi-mq > > > code reserves space in each scsi_cmnd for a scatterlist of > > > SCSI_MAX_SG_SEGMENTS. If scatterlists would be cached together with page > > > sets less memory would be needed per scsi_cmnd. > > > > If we go down this road how about also attaching some driver opaques > > to the page sets? > > That was the ultimate plan... to leave some opaques bytes left in the > page struct that drivers could use. > > In struct page I would need a pointer back to my page_pool struct and a > page flag. Then, I would need room to store the dma_unmap address. > (And then some of the usual fields are still needed, like the refcnt, > and reusing some of the list constructs). And a zero-copy cross-domain > id.
I don't think we need to add anything to struct page. This is supposed to be small cache of dma_mapped pages with lockless access. It can be implemented as an array or link list where every element is dma_addr and pointer to page. If it is full, dma_unmap_page+put_page to send it to back to page allocator.
