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

[Steffen Klassert <steffen.klassert@secunet.com>]

On Sat, Oct 07, 2023 at 09:17:59AM +0800, Wang Jinchao wrote:
> 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.

I had a closer look to the padata codebase now. The logic to
parallelize/serialize changed quite a bit since I wrote padata
initially. I don't understand the new logic completely,
so we need to rely on Daniels review for this.

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

pcrypt has performance gains if the cost of the crypto
oreration is higher than the cost of moving the crypto
request to another cpu. That was the case back in the
days, but the situation changed since then. We now have
hardware support for crypto, like aes-ni etc.
So for hardware supported algorithms, pcrypt will not
help much. But it is still interesting for crypto
algorithms that are implemented in software only.

Here is how you can instantiate a pcrypted
algorithm:

----------------------------------------------------
You need to instantiate pcrypt before you can use it.

You need either crconf or the tcrypt module to instantiate pcrypt.

With crconf:

You can get crconf from https://sourceforge.net/projects/crconf/
After installing crconf do e.g.

crconf add driver "pcrypt(authenc(hmac(sha1-generic),cbc(aes-asm)))" type 3


With tcrypt:

modprobe tcrypt alg="pcrypt(authenc(hmac(sha1-generic),cbc(aes-asm)))" type=3

The modprobe will return with an error, don't worry about it, that's ok.



Once you've did one of the above, your /proc/crypto should show
something like:

name         : authenc(hmac(sha1),cbc(aes))
driver       : pcrypt(authenc(hmac(sha1-generic),cbc(aes-asm)))
module       : pcrypt
priority     : 2100
refcnt       : 1
selftest     : passed
type         : aead
async        : yes
blocksize    : 16
ivsize       : 16
maxauthsize  : 20
geniv        : <built-in>


Now pcrypt is instantiated, e.g. all new IPsec states (that do
hmac-sha1, cbc-aes) will use it.