lkml.org 
[lkml]   [2022]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH] dma-iommu: Add iommu_dma_max_mapping_size()
From
On 17/05/2022 13:02, Robin Murphy wrote:
>>>
>>> Indeed, sorry but NAK for this being nonsense. As I've said at least
>>> once before, if the unnecessary SAC address allocation attempt slows
>>> down your workload, make it not do that in the first place. If you
>>> don't like the existing command-line parameter then fine, > there are
>>> plenty of
>>> other options, it just needs to be done in a way that doesn't break
>>> x86 systems with dodgy firmware, as my first attempt turned out to.
>>
>> Sorry, but I am not interested in this. It was discussed in Jan last
>> year without any viable solution.
>
> Er, OK, if you're not interested in solving that problem I don't see why
> you'd bring it up, but hey ho. *I* still think it's important, so I
> guess I'll revive my old patch with a CONFIG_X86 bodge and have another
> go at some point.

Let me rephrase, I would be happy to help fix that problem if we really
can get it fixed, however for my problem it's better to try to get the
SCSI driver to stop requesting uncached IOVAs foremost.

>
>> Anyway we still have the long-term IOVA aging issue, and requesting
>> non-cached IOVAs is involved in that. So I would rather keep the SCSI
>> driver to requesting cached IOVAs all the time.
>>
>> I did try to do it the other way around - configuring the IOVA caching
>> range according to the drivers requirement but that got nowhere.

Note that this is still not a final solution as it's not always viable
to ask a user to unbind + bind the driver.

>
> FWIW I thought that all looked OK, it just kept getting drowned out by
> more critical things in my inbox so I hoped someone else might comment.
> If it turns out that I've become the de-facto IOVA maintainer in
> everyone else's minds now and they're all waiting for my word then fair
> enough, I just need to know and reset my expectations accordingly. Joerg?

It would be great to see an improvement here...

>
>>> Furthermore, if a particular SCSI driver doesn't benefit from
>>> mappings larger than 256KB, then that driver is also free to limit
>>> its own mapping size. There are other folks out there with use-cases
>>> for mapping *gigabytes* at once; you don't get to cripple the API and
>>> say that that's suddenly not allowed just because it happens to make
>>> your thing go faster, that's absurd.
>>
>> I'd say less catastrophically slow, not faster.
>>
>> So how to inform the SCSI driver of this caching limit then so that it
>> may limit the SGL length?
>
> Driver-specific mechanism; block-layer-specific mechanism; redefine this
> whole API to something like dma_opt_mapping_size(), as a limit above
> which mappings might become less efficient or start to fail (callback to
> my thoughts on [1] as well, I suppose); many options.

ok, fine.

> Just not imposing
> a ridiculously low *maximum* on everyone wherein mapping calls "should
> not be larger than the returned value" when that's clearly bollocks.

I agree that this change is in violation as the documentation clearly
implies a hard limit.

However, FWIW, from looking at users of dma_max_mapping_size(), they
seem to use in a similar way to SCSI/block layer core, i.e. use this
value to limit the max SGL total len per IO command. And not as a method
to learn max DMA consistent mappings size for ring buffers, etc.

Anyway I'll look at dma_opt_mapping_size() but I am not sure how keen
Christoph will be on this... it is strange to introduce that API due to
peculiarity of the IOVA allocator.

>
>
> [1]
> https://lore.kernel.org/linux-iommu/20220510142109.777738-1-ltykernel@gmail.com/

Thanks,
John

\
 
 \ /
  Last update: 2022-05-17 15:51    [W:0.054 / U:1.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site