在 2022/9/20 15:31, Greg KH 写道:
On Mon, Sep 19, 2022 at 08:05:33PM +0800, Yang Shen wrote:
Provide a crypto benchmark to help the developer quickly get the
performance of a algorithm registered in crypto.
Due to the crypto algorithms have multifarious parameters, the tool
cannot support all test scenes. In order to provide users with simple
and easy-to-use tools and support as many test scenarios as possible,
benchmark refers to the crypto method to provide a unified struct
'crypto_bm_ops'. And the algorithm registers its own callbacks to parse
the user's input. In crypto, a algorithm class has multiple algorithms,
but all of them uses the same API. So in the benchmark, a algorithm
class uses the same 'ops' and distinguish specific algorithm by name.
First, consider the performance calculation model. Considering the
crypto subsystem model, a reasonable process code based on crypto api
should create a numa node based 'crypto_tfm' in advance and apply for
a certain amount of 'crypto_req' according to their own business.
In the real business processing stage, the thread send tasks based on
'crypto_req' and wait for completion.
Therefore, the benchmark will create 'crypto_tfm' and 'crypto_req' at
first, and then count all requests time to calculate performance.
So the result is the pure algorithm performance. When each algorithm
class implements its own 'ops', it needs to pay attention to the content
completed in the callback. Before the 'ops.perf', the tool had better
prepare the request data set. And in order to avoid the false high
performance of the algorithm caused by the false cache and TLB hit rate,
the size of data set should be larger than 'crypto_req' number.
The 'crypto_bm_ops' has following api:
- init & uninit
The initialize related functions. Algorithm can do some private setting.
- create_tfm & release_tfm
The 'crypto_tfm' related functions. Algorithm has different tfm name in
crypto. But they both has a member named tfm, so use tfm to stand for
algorithm handle. The benchmark has provides the tfm array.
- create_req & release_req
The 'crypto_req' related functions. The callbacks should create a 'reqnum'
'crypto_req' group in struct 'crypto_bm_base'. And the also suggest
prepare the request data in this function. In order to avoid the false
high performance of the algorithm caused by the false cache and TLB hit
rate, the size of data set should be larger than 'crypto_req' number.
- perf
The request sending functions. The registrant should use parameter 'loop'
to send requests repeatly. And update the count in struct
'crypto_bm_thread_data'.
Then consider the parameters that user can configure. Generally speaking,
the following parameters will affect the performance of the algorithm:
tfm number, request number, block size, numa node. And some parameters
will affect the stability of performance: testing time and requests sent
number. To sum up, the benchmark has following parameters:
- algorithm
The testing algorithm name. Showed in /proc/crypto.
- algtype
The testing algorithm class. Can get the algorithm class by echo 'algtype'
to /sys/module/crypto_benchmark/parameters/help.
- inputsize
The testing length that can greatly impact performance. Such as data size
for compress or key length for encryption.
- loop
The testing loop times. Avoid performance fluctuations caused by
environment.
- numamask
The testing bind numamask. Used for allocate memory, create threads and
create 'crypto_tfm'.
- optype
The testing algorithm operation type. Can get the algorithm available
operation types by cat /sys/module/crypto_benchmark/parameters/help
with specified 'algtype'.
- reqnum
The testing request number for per tfm. Used for test asynchrony api
performance.
- threadnum
The testing thread number. To simplify model, create a 'crypto_tfm' per
thread.
- time
The testing time. Used for stop the test thread.
- run
Start or stop the test.
Users can configure parameters under
/sys/modules/crypto_benchmark/parameters/.
Please don't use module parameters for stuff like this, use configfs
which was designed for this type of interactions.
thanks,
greg k-h
Got it!
Thanks,
Yang
