linux-kernel - Re: [PATCH v4 1/5] dma-mapping: Add dma_opt_mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <416ebe33-28ed-eef0-0001-83efd83a9d0f@huawei.com>
Date:   Wed, 29 Jun 2022 12:57:54 +0100
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....com>
CC:     <linux-scsi@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linuxarm@...wei.com>, <iommu@...ts.linux.dev>,
        <linux-kernel@...r.kernel.org>, <linux-ide@...r.kernel.org>,
        <iommu@...ts.linux-foundation.org>,
        <damien.lemoal@...nsource.wdc.com>, <jejb@...ux.ibm.com>,
        <martin.petersen@...cle.com>, <m.szyprowski@...sung.com>,
        <joro@...tes.org>, <hch@....de>, <will@...nel.org>
Subject: Re: [PATCH v4 1/5] dma-mapping: Add dma_opt_mapping_size()

On 28/06/2022 12:27, John Garry via iommu wrote:
> On 28/06/2022 12:23, Robin Murphy wrote:
>>> +
>>> +    size_t
>>> +    dma_opt_mapping_size(struct device *dev);
>>> +
>>> +Returns the maximum optimal size of a mapping for the device. 
>>> Mapping large
>>> +buffers may take longer so device drivers are advised to limit total 
>>> DMA
>>> +streaming mappings length to the returned value.
>>
>> Nit: I'm not sure "advised" is necessarily the right thing to say in 
>> general - that's only really true for a caller who cares about 
>> throughput of churning through short-lived mappings more than anything 
>> else, and doesn't take a significant hit overall from splitting up 
>> larger requests. I do think it's good to clarify the exact context of 
>> "optimal" here, but I'd prefer to be objectively clear that it's for 
>> workloads where the up-front mapping overhead dominates.
> 
I'm going to go with something like this:

size_t
dma_opt_mapping_size(struct device *dev);

Returns the maximum optimal size of a mapping for the device.

Mapping larger buffers may take much longer in certain scenarios. In 
addition, for high-rate short-lived streaming mappings the upfront time 
spent on the mapping may account for an appreciable part of the total 
request lifetime. As such, if splitting larger requests incurs no 
significant performance penalty, then device drivers are advised to 
limit total DMA streaming mappings length to the returned value.

Let me know if you would like it further amended.

Cheers,
John