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?
