[RFC,5/6] crypto: benchmark - add API documentation

diff --git a/Documentation/crypto/benchmark.rst b/Documentation/crypto/benchmark.rst
new file mode 100644
index 000000000000..e9b13e81bce3
--- /dev/null
+++ b/Documentation/crypto/benchmark.rst
@@ -0,0 +1,104 @@ 
+.. SPDX-License-Identifier: GPL-2.0
+
+Crypto Benchmark
+================
+
+Overview
+--------
+The crypto benchmark is a crypto algorithm performance tool.
+
+Designed Scheme
+---------------
+
+1. Parameters
+
+The crypto benchmark is used for test the algorithm registered in crypto
+subsystem. Users can use module parameters to simulate different scenarios.
+Both considering the test scenarios and the use complexity, the benchmark
+tool has following module parameters:
+
+- algorithm
+The 'algorithm' is used to create a 'crypto_tfm'. The right algorithm name
+can be found in /proc/crypto.
+
+- algtype
+The 'algtype' is used to find the operations of algorithm. Can get the
+algorithm class by echo 'algtype' to
+/sys/module/crypto_benchmark/parameters/help.
+
+- inputsize
+The 'inputsize' is used as testing inputsize, outputsize will be set
+according to algorithm.
+
+- loop
+The 'loop' is used as times to try to send request for one 'crypto_req'.
+Avoid performance fluctuations caused by environment.
+For synchronization mode, the loop times is equal to send times.
+But for asynchronization, the send times is often less than loop times.
+
+- numamask
+The 'numamask' is used as testing binding numa nodes. The input will be
+analyzed as a bitmap.
+
+- optype
+The 'optype' is used for choose algorithm operation function. Can get the
+algorithm available operation types by cat
+/sys/module/crypto_benchmark/parameters/help with specified 'algtype'.
+For example, choose the compress and decompress when test crypto comp.
+
+- reqnum
+The 'reqnum' is used as requests number of a crypto tfm. For asynchronization,
+one thread may used plural 'crypto_req' to improve performance. One request
+a thread is a synchronous model
+
+- threadnum
+The 'threadnum' is used for creating testing threads. To simplify model,
+create a 'crypto_tfm' per thread. Notice that all threads will be divided
+equally to the specified NUMA node, and threads that cannot be divided
+equally will be created on the last node.
+
+- time
+The 'time' is used for testing. Used for stop the test thread. If the time
+is not enough, the thread will send another group loop times requests.
+
+- run
+The 'run' is used to trigger the test. Echo 0 for stop all test threads,
+and others for starting test.
+
+- help
+The 'help' is used to guide users to use the test interface. Echo a module
+parameter name to 'help' can get the detailed information. Cat the 'help'
+can get some private  information according to 'algtype'.
+
+2. Register
+
+There are too many differences between crypto algorithms. Therefore, the
+crypto benchmark only completes the general work. All the different parts
+are put into the callback of the algorithm to complete. The usual crypto
+task can be divided into three parts: alloc tfm, alloc request, and send
+request.
+
+A new algorithm class want to register to crypto benchmark should realize
+following callbacks:
+
+- 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.
+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 registrant should create a 'reqnum'
+'crypto_req' group in struct 'crypto_bm_base'. And the also suggest
+prepare the request data in this function. To simulate real cache and TLB
+hit rate, using a big data groups is a good plan.
+
+- 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'.
+
+- help
+The algorithm private parameters meaning functions.