[PATCH v2] iommu/arm-smmu-v3: disable MSI polling if SEV polling is faster

[Will Deacon]

On Fri, Jul 31, 2020 at 10:48:33AM +0000, Song Bao Hua (Barry Song) wrote:
> > -----Original Message-----
> > From: John Garry
> > Sent: Friday, July 31, 2020 10:21 PM
> > To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>; will at kernel.org;
> > robin.murphy at arm.com; joro at 8bytes.org; iommu at lists.linux-foundation.org
> > Cc: Zengtao (B) <prime.zeng at hisilicon.com>; Linuxarm
> > <linuxarm at huawei.com>; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH v2] iommu/arm-smmu-v3: disable MSI polling if SEV
> > polling is faster
> > 
> > On 31/07/2020 09:33, Barry Song wrote:
> > > Different implementations may show different performance by using SEV
> > > polling or MSI polling.
> > > On the implementation of hi1620, tests show disabling MSI polling can
> > > bring performance improvement.
> > > Using 16 threads to run netperf on hns3 100G NIC with UDP packet size
> > > in 32768bytes and set iommu to strict, TX throughput can improve from
> > > 25Gbps to 27Gbps by this patch.
> > > This patch adds a generic function to support implementation options
> > > based on IIDR and disables MSI polling if IIDR matches the specific
> > > implementation tested.
> > Not sure if we should do checks like this on an implementation basis.
> > I'm sure maintainers will decide.
> 
> Yes, maintainers will decide. I guess Will won't object to IIDR-based solution according to
> previous discussion threads:
> https://lore.kernel.org/patchwork/patch/783718/
> 
> Am I right, Will?

Honestly, I object to the whole idea that we should turn off optional
hardware features just because they're slow. Did nobody take time to look at
the design and check that it offered some benefit, or where they in too much
of a hurry to tick the checkbox to say they had the new feature? I really
dislike the pick and mix nature that some of this IP is heading in, where
the marketing folks want a slice of everything for the branding, instead of
doing a few useful things well. Anyway, that's not your fault, so I'll stop
moaning. *sigh*

Given that you've baked this thing now, then if we have to support it I
would prefer the command-line option. At least that means that people can
compare the performance with it on and off (and hopefully make sure the
hardware doesn't suck). It also means it's not specific to ACPI.

Will