Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3dd984c1-d17f-0a6a-c52e-87e161f867fc@huawei.com>
Date:   Wed, 21 Sep 2022 16:19:18 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.1.2
Subject: Re: [RFC PATCH 0/6] crypto: benchmark - add the crypto benchmark
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     <davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
        <linux-crypto@vger.kernel.org>, <gregkh@linuxfoundation.org>
References: <20220919120537.39258-1-shenyang39@huawei.com>
 <Yyl5yKQCAgPBbFd7@gondor.apana.org.au>
From:   Yang Shen <shenyang39@huawei.com>
In-Reply-To: <Yyl5yKQCAgPBbFd7@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


在 2022/9/20 16:28, Herbert Xu 写道:
> On Mon, Sep 19, 2022 at 08:05:31PM +0800, Yang Shen wrote:
>> Add crypto benchmark - A tool to help the users quickly get the
>> performance of a algorithm registered in crypto.
> Please explain how this relates to the existing speed testing
> functionality in tcrypt.
>
> Thanks,

In fact, the purpose for I is to get a crypto benchmark tool which is 
customizable
and easy to called. For example, I test the hardware performance every 
rc1 to check
whether the modification of the common module affects it. For me, I need 
to test
the mutil threads, mutil numas, mutil requests of one tfm and so on. 
These test
cases are used to simulate some service scenarios. And in these cases, I 
can find
if any common module apply a patch that has an impact on us.

I know the tcrypt.ko has the speed test cases. But the tcrypt.ko test 
case is fixed.
If I understand correctly, the design model of tcrypt.ko is test the 
algorithms with
determined case conditions. It can provide some standardized testing to 
ensure
that the implementation of the algorithm meets the requirements. This is a
reasonable developer test tool, but it is not flexible enough for 
testers and users.

There are two main reasons for this:
1> For testers, the performance is not only related to algorithms and 
algorithm
configurations. Many configurations may have obvious effect on 
performance which
are not provided on tcrypt.ko. Of course, this problem can fix by add 
these as module
parameters.
2> For users, a friendly tool is that they can use the tool directly 
rather to need to
watch the source code to know how to use it. In tcrypt.ko, users need to 
get the 'mode'
number of case they want to test if exist.

So this tool's original intention is to allow users test more complex 
scenarios and get the
parameters usage directly.

If I have any misunderstanding about tcrypt.ko, please correct me. And 
I'll try to use the
tcrytp.ko to meet my request.

Thanks,

Yang