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

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

[Wang Jinchao]

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? Because I've noticed a significant maintenance cost related to CPUs. Are there any specific benefits?

- In what scenarios is it necessary to specify a CPU for serial execution, or is ensuring the order sufficient?

In fact, the two questions can be summarized into one: Is it possible to avoid handling CPU-related operations to simplify the code logic?

Thanks.

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

[Daniel Jordan]

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/

> 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.

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

[Wang Jinchao]

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.

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

[Daniel Jordan]

On Sat, Oct 07, 2023 at 10:56:31AM +0800, Wang Jinchao wrote:
> 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?

Yes, it's entirely based on performance.  In the tests I ran, padata did
a lot better when it was free to run parallel works on any CPU in case
some were busy.

> > > 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?

Well, yeah.  In this case, I'm not sure it's necessary--it looks to me
like it's not--but Steffen might have had a reason for cb_cpu that I'm
not aware of.

> 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?

It looks like Steffen has given some hints on testing with IPsec in
another thread.