linux-kernel - Re: [PATCH v2 0/3] crypto: hisilicon - add fallback function for hisilicon accelerater driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <422b6648-6668-4f40-b79e-4611936576c6@huawei.com>
Date: Tue, 26 Aug 2025 19:52:16 +0800
From: huangchenghai <huangchenghai2@...wei.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: <davem@...emloft.net>, <linux-kernel@...r.kernel.org>,
	<linux-crypto@...r.kernel.org>, <qianweili@...wei.com>,
	<linwenkai6@...ilicon.com>, <wangzhou1@...ilicon.com>, <taoqi10@...wei.com>
Subject: Re: [PATCH v2 0/3] crypto: hisilicon - add fallback function for
 hisilicon accelerater driver


On Tue, Aug 26, 2025 at 09:59 AM +0800, Herbert Xu wrote:
> On Mon, Aug 25, 2025 at 09:00:37PM +0800, huangchenghai wrote:
>> We currently do not support sharing hardware queues between tfm
>> objects. Our rationale is as follows:
>> a) Queue multiplexing (allowing multiple tfms to share a queue)
>> theoretically improves resource utilization. However, hardware
>> resources are shared among all queues, and performance is also
>> shared. Once the hardware reaches its physical limits, all new
>> services can only queue up in the queue. Therefore, reuse will only
>> make the queue longer, not increase processing speed, and instead
>> increase business waiting latency. In cases of insufficient queues,
>> it is better to directly fallback to software processing.
>>
>> In benchmark tests, only 16 queues or tfms are needed to achieve
>> full hardware bandwidth performance.
>>
>> b) After a queue is initialized by a tfm, if a new tfm has a
>> different algorithm from the original queue, it cannot share the
>> queue. Queue reuse is limited by the type of tfm algorithm.
> Sorry but this is not acceptable.  The number of tfms are meant
> to be large.  If your driver isn't able to support that then it
> should be just deleted.
>
> Thanks,
Okay, we will decouple the hardware queue constraints from the
number of tfm to adapt to Crypto.

Thanks
Chenghai