[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4f9184c5-e6a2-08da-f44a-3000b6cdfe35@oracle.com>
Date: Thu, 15 Jun 2023 08:49:18 +0100
From: John Garry <john.g.garry@...cle.com>
To: Jakub Kicinski <kuba@...nel.org>, Joerg Roedel <joro@...tes.org>
Cc: Robin Murphy <robin.murphy@....com>, will@...nel.org,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v4] iommu: Optimise PCI SAC address trick
On 13/06/2023 18:58, Jakub Kicinski wrote:
> On Fri, 14 Apr 2023 13:45:34 +0200 Joerg Roedel wrote:
>> Thanks for working on this, I think this is good to go. But given the
>> issues we had with last attempt I'd like to have this in linux-next for
>> a few weeks before sending it upstream. Therefore I will defer this
>> patch and merge it early in the next cycle.
> Is this patch queued up? I don't see it in linux-next and we keep
> hitting this issue in production. After a few NIC reconfigurations
> IOMMU starts consuming 90+% of CPU time.
>
Since we're at rc6 time and a cautious approach was wanted to merge this
change, I doubt that this will be merged for this cycle. That's quite
unfortunate.
Please note what I mentioned earlier about using dma_opt_mapping_size().
This API is used by some block storage drivers to avoid your same
problem, by clamping max_sectors_kb at this size - see sysfs-block Doc
for info there. Maybe it can be used similarly for network drivers.
Thanks,
John
Powered by blists - more mailing lists