[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <42505bbc-7319-f266-f282-e76ba505725e@huawei.com>
Date: Fri, 1 Jul 2022 09:46:34 +0100
From: John Garry <john.garry@...wei.com>
To: Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
<joro@...tes.org>, <will@...nel.org>, <jejb@...ux.ibm.com>,
<martin.petersen@...cle.com>, <hch@....de>,
<m.szyprowski@...sung.com>, <robin.murphy@....com>
CC: <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-ide@...r.kernel.org>, <iommu@...ts.linux-foundation.org>,
<iommu@...ts.linux.dev>, <linux-scsi@...r.kernel.org>,
<linuxarm@...wei.com>
Subject: Re: [PATCH v5 4/5] scsi: scsi_transport_sas: Cap shost max_sectors
according to DMA optimal limit
On 01/07/2022 00:49, Damien Le Moal wrote:
>>
>> + if (dma_dev) {
>> + shost->max_sectors = min_t(unsigned int, shost->max_sectors,
>> + dma_opt_mapping_size(dma_dev) >> SECTOR_SHIFT);
>> + }
Hi Damien,
> Hmm... shost->max_sectors becomes the max_hw_sectors limit for the block
> dev. So using dma_max_mapping_size(dma_dev) for that limit makes sense.
> Shouldn't dma_opt_mapping_size(dma_dev) be used to limit only the default
> "soft" limit (queue max_sectors limit) instead of the hard limit ?
>
Sure, it would sensible to use dma_opt_mapping_size() to limit the
default queue max sectors limit, while dma_max_mapping_size() limits the
host max sectors. But I didn't see in practice how limiting the shost
max sectors to dma_opt_mapping_size() makes a difference:
- block queue max_hw_sectors_kb file is read-only, so we cannot change
the queue max sectors from there
- And no SAS driver actually tries to modify upwards from the default.
I do note that USB storage driver as an example of a scsi driver which
does (modify from shost max sectors): see scsiglue.c::slave_configure()
Finally there is no common method to limit the default request queue max
sectors for those SAS drivers - I would need to add this limit in each
of their slave_configure callbacks, and I didn't think that its worth it.
Thanks,
John
Powered by blists - more mailing lists