linux-kernel - Re: Issue: Can padata avoid dealing with CPU-related operations?

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]

Message-ID: <ZSDI34RMdJ7es7hj@fedora>
Date:   Sat, 7 Oct 2023 10:56:31 +0800
From:   Wang Jinchao <wangjinchao@...sion.com>
To:     Daniel Jordan <daniel.m.jordan@...cle.com>
CC:     Steffen Klassert <steffen.klassert@...unet.com>,
        <linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <stone.xulei@...sion.com>
Subject: Re: Issue: Can padata avoid dealing with CPU-related operations?

On Wed, Oct 04, 2023 at 10:52:57AM -0400, Daniel Jordan wrote:
> Hi,
> 
> On Wed, Sep 27, 2023 at 09:25:54PM +0800, Wang Jinchao wrote:
> > Hello, I have a few questions about the padata code I've been studying
> > recently:
> > 
> > - Why does padata use the WQ_UNBOUND attribute of the workqueue?
> 
> There's background in this series:
>     https://lore.kernel.org/all/20190813005224.30779-1-daniel.m.jordan@oracle.com/
> 
Summarizing, the use of the WQ_UNBOUND attribute is primarily based on performance
considerations. Is this understanding correct?
> > Because I've noticed a significant maintenance cost related to CPUs.
> > Are there any specific benefits?
> 
> Aside from what Steffen said about serialization, the pcrypt cpumasks
> can be set from sysfs to control where parallel and serial jobs run.
> 
> > - In what scenarios is it necessary to specify a CPU for serial
> > execution, or is ensuring the order sufficient?
> 
> I'm not sure that it's necessary.  The way I read it, at least, it seems
> pcrypt uses cb_cpu to load balance serialization across all CPUs allowed
> in the serial cpumask.

I recognize that the key issue isn't the capabilities it can offer, but rather
the underlying necessity for these capabilities. If the need isn't particularly
strong and the cost of implementing this capability is high, should we consider
omitting it?

As previously mentioned in another email, I'm seeking guidance on how to effectively 
evaluate the timing of padata serialization in a network environment. 
Could you provide some insights or pointers on this matter?

Furthermore, I'd like to extend my sincere gratitude for your recent responses 
and would appreciate discussing my future steps with you. 
Thank you.