Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
IronPort-SDR: QyER1Napp0Z+6TMZAuyDwa9lHtILvV9lm1REaK+L096DLOaWI3zBze9izGrLHKrLvB+m1mh3Op
 QoriEYxLvoLY14zvet9s/Jiwl3meMbHDe2KHc5miRXk3Q3IE7t/w8LwnetfQBWF71OIFqKUZby
 C/QZhqRMmcAAEAbLWJyz/1mCmzvqdiFVrnnv2F58q9VPjCHJVKUNpegFfe6aKqjrKF5Q0U6VJ8
 sh8hd0dBen8Q+Xg8frjahs2HWMAuOIauP3D5Fr49bTUKp0BFvsu97cxq4mxoGBdgZVRr2U+W9E
 zp1uFaVbpqqFUIdwqdLc6ASu
IronPort-SDR: 9X40ZBwz0xtVvrgUPyeqZOelz+gNE4Knf9dVCFzBqOioAAJ7djuK6yYTiYY0Ypd2II+jmMAf5T
 H21sR2jjP56ntVxgrq3KM4aZ8nvXJY1sc7SsV/H0zebI4foCQ//niY5Ex0cdEFw2J47AMvhKX1
 +7eSo9R6MJy0fxcdPrPecIQBS5F0TVFdW2Z5ksRk4xftVG5dQI0BB+jr/dGUvtL3RMKUQT5E5S
 RuLiT9FbjSuPB1t6yUxB1SqtnRLV/uLxKdz51wxSXw8Z2VeDAHGl/dZ7F5O/qVhHaSP+nPAS+h
 ZFI=
WDCIronportException: Internal
Message-ID: <6367a264-a3d3-8857-9b5a-2afcd25580cb@opensource.wdc.com>
Date:   Mon, 11 Jul 2022 08:08:23 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v5 0/5] DMA mapping changes for SCSI core
Content-Language: en-US
To:     John Garry <john.garry@huawei.com>,
        "Martin K. Petersen" <martin.petersen@oracle.com>,
        Christoph Hellwig <hch@lst.de>
Cc:     joro@8bytes.org, will@kernel.org, jejb@linux.ibm.com,
        m.szyprowski@samsung.com, robin.murphy@arm.com,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-ide@vger.kernel.org, iommu@lists.linux-foundation.org,
        iommu@lists.linux.dev, linux-scsi@vger.kernel.org,
        linuxarm@huawei.com
References: <1656590892-42307-1-git-send-email-john.garry@huawei.com>
 <b5f80062-e8ef-9597-1b0c-393140950dfb@huawei.com>
 <20220706134447.GA23753@lst.de> <yq1y1x47jgn.fsf@ca-mkp.ca.oracle.com>
 <5fd4814a-81b1-0e71-58e0-57a747eb684e@huawei.com>
From:   Damien Le Moal <damien.lemoal@opensource.wdc.com>
Organization: Western Digital Research
In-Reply-To: <5fd4814a-81b1-0e71-58e0-57a747eb684e@huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 7/9/22 01:17, John Garry wrote:
> On 07/07/2022 21:35, Martin K. Petersen wrote:
>> Christoph,
>>
>>> Yes, I've mostly been waiting for an ACK from Martin.
>> Sorry, I'm on vacation this week. The series looks OK to me although I
>> do agree that it would be great if the max was reflected in the queue'=
s
>> hard limit and opt in the soft limit.
>=20
> Ah, I think that I misunderstood Damien's question. I thought he was=20
> asking why not keep shost max_sectors at dma_max_mapping_size() and the=
n=20
> init each sdev request queue max hw sectors at dma_opt_mapping_size().

I was suggesting the reverse :) Keep the device hard limit
(max_hw_sectors) to the max dma mapping and set the soft limit
(max_sectors) to the optimal dma mapping size.

>=20
> But he seems that you want to know why not have the request queue max=20
> sectors at dma_opt_mapping_size(). The answer is related to meaning of=20
> dma_opt_mapping_size(). If we get any mappings which exceed this size=20
> then it can have a big dma mapping performance hit. So I set max hw=20
> sectors at this =E2=80=98opt=E2=80=99 mapping size to ensure that we ge=
t no mappings=20
> which exceed this size. Indeed, I think max sectors is 128Kb today for=20
> my host, which would be same as dma_opt_mapping_size() value with an=20
> IOMMU enabled. And I find that only a small % of request size may excee=
d=20
> this 128kb size, but it still has a big performance impact.
>=20
>>
>> Acked-by: Martin K. Petersen<martin.petersen@oracle.com>
>=20
> Thanks,
> John


--=20
Damien Le Moal
Western Digital Research