Re: [RFC/REFACT] Refactoring and significantly reducing code complexity

[Wang Jinchao <wangjinchao@xfusion.com>]

On Fri, Sep 29, 2023 at 07:47:22AM +0200, Steffen Klassert wrote:
> On Thu, Sep 28, 2023 at 04:53:38PM +0800, Wang Jinchao wrote:
> > This is a refactored version with the following main changes:
> > 
> > - The parallel workqueue no longer uses the WQ_UNBOUND attribute
> > - Removal of CPU-related logic, sysfs-related interfaces
> > - removal of structures like padata_cpumask, and deletion of parallel_data
> > - Using completion to maintain sequencing
> > - no longer using lists
> > - removing structures like padata_list and padata_serial_queue
> > - Removal of padata_do_serial()
> 
> This removes all the logic that is needed to ensure that
> the parallelized objects return in the same order as
> they were before the parallelization. This change makes
> padata unusable for networking.

The RFC use the following three to ensure serial timing sequence:

1.  Use alloc_ordered_workqueue() to create a serial worker queue where 
    serial() function runs. This ensures that serial() function executes
    as serial work was enqueued using queue_work().
2.  Queue the serial work before enqueueing parallel work in padata_do_parallel().
    This ensures the serial work follows the same order as the padata_do_parallel().
3.  The serial work wait for completion of parallel_done, which will be 
    complete()ed after the parallel() function within the parallel work.

This is just a design idea, because I am not familiar with IPsec, I haven't 
tested it in a real network environment yet. 
Could you give me some clues on how to use pcrypt in an IPsec scenario?