Re: [PATCH 3/4] scsi: core: Cap shost max_sectors according to DMA optimum mapping limits

2022-05-20 Thread Damien Le Moal via iommu
On 5/20/22 17:23, John Garry wrote: > Streaming DMA mappings may be considerably slower when mappings go through > an IOMMU and the total mapping length is somewhat long. This is because the > IOMMU IOVA code allocates and free an IOVA for each mapping, which may > affect performance. > > For perf

Re: [PATCH 2/4] dma-iommu: Add iommu_dma_opt_mapping_size()

2022-05-20 Thread Damien Le Moal via iommu
On 5/20/22 17:23, John Garry wrote: > Add the IOMMU callback for DMA mapping API dma_opt_mapping_size(), which > allows the drivers to know the optimal mapping limit and thus limit the > requested IOVA lengths. > > This value is based on the IOVA rcache range limit, as IOVAs allocated > above this

Re: [PATCH 4/4] libata-scsi: Cap ata_device->max_sectors according to shost->max_sectors

2022-05-20 Thread Damien Le Moal via iommu
On 5/20/22 17:23, John Garry wrote: > ATA devices (struct ata_device) have a max_sectors field which is > configured internally in libata. This is then used to (re)configure the > associated sdev request queue max_sectors value from how it is earlier set > in __scsi_init_queue(). In __scsi_init_que

Re: [PATCH 1/4] dma-mapping: Add dma_opt_mapping_size()

2022-05-20 Thread Damien Le Moal via iommu
On 5/20/22 17:23, John Garry wrote: > Streaming DMA mapping involving an IOMMU may be much slower for larger > total mapping size. This is because every IOMMU DMA mapping requires an > IOVA to be allocated and freed. IOVA sizes above a certain limit are not > cached, which can have a big impact on

Re: [PATCH 0/4] DMA mapping changes for SCSI core

2022-05-22 Thread Damien Le Moal via iommu
On 2022/05/22 22:13, Christoph Hellwig wrote: > The whole series looks fine to me. I'll happily queue it up in the > dma-mapping tree if the SCSI and ATA maintainers are ok with that. > Fine with me. I sent an acked-by for the libata bit. -- Damien Le Moal Western Digital Research

Re: [PATCH 2/4] dma-iommu: Add iommu_dma_opt_mapping_size()

2022-05-23 Thread Damien Le Moal via iommu
On 2022/05/23 16:01, John Garry wrote: > On 21/05/2022 00:33, Damien Le Moal wrote: > > Hi Damien, > >>> +unsigned long iova_rcache_range(void) >> Why not a size_t return type ? > > The IOVA code generally uses unsigned long for size/range while > dam-iommu uses size_t as appropiate, so I'm jus

Re: [PATCH 3/4] scsi: core: Cap shost max_sectors according to DMA optimum mapping limits

2022-05-23 Thread Damien Le Moal via iommu
On 2022/05/23 15:53, John Garry wrote: > On 21/05/2022 00:30, Damien Le Moal wrote: >>> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c >>> index f69b77cbf538..a3ae6345473b 100644 >>> --- a/drivers/scsi/hosts.c >>> +++ b/drivers/scsi/hosts.c >>> @@ -225,6 +225,11 @@ int scsi_add_host_with_

Re: [PATCH 2/4] dma-iommu: Add iommu_dma_opt_mapping_size()

2022-05-23 Thread Damien Le Moal via iommu
On 2022/05/20 17:23, John Garry wrote: > Add the IOMMU callback for DMA mapping API dma_opt_mapping_size(), which > allows the drivers to know the optimal mapping limit and thus limit the > requested IOVA lengths. > > This value is based on the IOVA rcache range limit, as IOVAs allocated > above t

Re: [PATCH v2 2/4] dma-iommu: Add iommu_dma_opt_mapping_size()

2022-05-26 Thread Damien Le Moal via iommu
On 2022/05/26 19:28, John Garry wrote: > Add the IOMMU callback for DMA mapping API dma_opt_mapping_size(), which > allows the drivers to know the optimal mapping limit and thus limit the > requested IOVA lengths. > > This value is based on the IOVA rcache range limit, as IOVAs allocated > above t

Re: [PATCH v4 5/5] libata-scsi: Cap ata_device->max_sectors according to shost->max_sectors

2022-06-27 Thread Damien Le Moal via iommu
On 6/28/22 00:25, John Garry wrote: > ATA devices (struct ata_device) have a max_sectors field which is > configured internally in libata. This is then used to (re)configure the > associated sdev request queue max_sectors value from how it is earlier set > in __scsi_init_queue(). In __scsi_init_que

Re: [PATCH v4 5/5] libata-scsi: Cap ata_device->max_sectors according to shost->max_sectors

2022-06-28 Thread Damien Le Moal via iommu
On 6/28/22 16:54, John Garry wrote: > On 28/06/2022 00:24, Damien Le Moal wrote: >> On 6/28/22 00:25, John Garry wrote: >>> ATA devices (struct ata_device) have a max_sectors field which is >>> configured internally in libata. This is then used to (re)configure the >>> associated sdev request queue

Re: [PATCH v4 5/5] libata-scsi: Cap ata_device->max_sectors according to shost->max_sectors

2022-06-28 Thread Damien Le Moal via iommu
On 6/29/22 14:40, Christoph Hellwig wrote: > On Tue, Jun 28, 2022 at 12:33:58PM +0100, John Garry wrote: >> Well Christoph originally offered to take this series via the dma-mapping >> tree. >> >> @Christoph, is that still ok with you? If so, would you rather I send this >> libata patch separatel

Re: [PATCH v4 5/5] libata-scsi: Cap ata_device->max_sectors according to shost->max_sectors

2022-06-29 Thread Damien Le Moal via iommu
On 6/29/22 16:43, John Garry wrote: > On 29/06/2022 06:58, Damien Le Moal wrote: >> On 6/29/22 14:40, Christoph Hellwig wrote: >>> On Tue, Jun 28, 2022 at 12:33:58PM +0100, John Garry wrote: Well Christoph originally offered to take this series via the dma-mapping tree. @Christo

Re: [PATCH v5 3/5] scsi: core: Cap shost max_sectors according to DMA limits only once

2022-06-30 Thread Damien Le Moal via iommu
On 6/30/22 21:08, John Garry wrote: > The shost->max_sectors is repeatedly capped according to the host DMA > mapping limit for each sdev in __scsi_init_queue(). This is unnecessary, so > set only once when adding the host. > > Signed-off-by: John Garry > --- > drivers/scsi/hosts.c| 5 +

Re: [PATCH v5 4/5] scsi: scsi_transport_sas: Cap shost max_sectors according to DMA optimal limit

2022-06-30 Thread Damien Le Moal via iommu
On 6/30/22 21:08, John Garry wrote: > Streaming DMA mappings may be considerably slower when mappings go through > an IOMMU and the total mapping length is somewhat long. This is because the > IOMMU IOVA code allocates and free an IOVA for each mapping, which may > affect performance. > > For perf