[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2585983-75d7-c627-13ba-38a464cf716e@acm.org>
Date: Thu, 9 Jun 2022 10:18:40 -0700
From: Bart Van Assche <bvanassche@....org>
To: John Garry <john.garry@...wei.com>,
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,
linux-scsi@...r.kernel.org, liyihang6@...ilicon.com,
chenxiang66@...ilicon.com, thunder.leizhen@...wei.com
Subject: Re: [PATCH v3 3/4] scsi: core: Cap shost max_sectors according to DMA
optimum mapping limits
On 6/9/22 01:00, John Garry wrote:
> On 08/06/2022 22:07, Bart Van Assche wrote:
>> On 6/8/22 10:50, John Garry wrote:
>>> Please note that this limit only applies if we have an IOMMU enabled
>>> for the scsi host dma device. Otherwise we are limited by dma direct
>>> or swiotlb max mapping size, as before.
>>
>> SCSI host bus adapters that support 64-bit DMA may support much larger
>> transfer sizes than 128 KiB.
>
> Indeed, and that is my problem today, as my storage controller is
> generating DMA mapping lengths which exceeds 128K and they slow
> everything down.
>
> If you say that SRP enjoys best peformance with larger transfers then
> can you please test this with an IOMMU enabled (iommu group type DMA or
> DMA-FQ)?
Hmm ... what exactly do you want me to test? Do you perhaps want me to
measure how much performance drops with an IOMMU enabled? I don't have
access anymore to the SRP setup I referred to in my previous email. But
I do have access to devices that boot from UFS storage. For these
devices we need to transfer 2 MiB per request to achieve full bandwidth.
Thanks,
Bart.
Powered by blists - more mailing lists