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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 1 Jun 2023 23:18:44 +0800
From:   Huacai Chen <chenhuacai@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Marc Zyngier <maz@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn,
        Xuefeng Li <lixuefeng@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: [PATCH 1/2] genirq/msi, platform-msi: Adjust return value of msi_domain_prepare_irqs()

Hi, Thomas,

On Tue, May 30, 2023 at 11:03 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Tue, May 30 2023 at 16:34, Huacai Chen wrote:
> > On Tue, May 30, 2023 at 4:19 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> >> Let's take a step back and look at the larger picture:
> >>
> >>  1) A PCI/MSI irqdomain is attached to a PCI bus
> >>
> >>  2) The number of PCI devices on that PCI bus is usually known at boot
> >>     time _before_ the first device driver is probed.
> >>
> >>     That's not entirely true for PCI hotplug devices, but that's hardly
> >>     relevant for an architecture which got designed less than 10 years
> >>     ago and the architects decided that 256 MSI vectors are good enough
> >>     for up to 256 CPUs. The concept of per CPU queues was already known
> >>     at that time, no?
> > Does this solution depend on the per-device msi domain? Can we do that
> > if we use the global msi domain?
>
> In principle it should not depend on per-device MSI domains, but I
> really don't want to add new functionality to the old operating models
> as that does not create an incentive for people to convert their stuff
> over.
Thank you for your advice, but for our scenario, its effect is no
better than this patch (because not all devices are aggressive
devices), so we give up. :)

And as Jason said in another thread, this problem can be solved by
simply reducing the number of queues by ethtool. So let's ignore this
patch since it is not acceptable.

Huacai
>
> >> So the irqdomain can tell the PCI/MSI core the maximum number of vectors
> >> available for a particular bus, right?
> >>
> >> The default, i.e if the irqdomain does not expose that information,
> >> would be "unlimited", i.e. ULONG_MAX.
> > OK, thanks, but how to expose? By msi_domain_info::hwsize?
>
> Probably. Needs a proper helper around it.
>
> Thanks,
>
>         tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ