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

[huangchenghai <huangchenghai2@huawei.com>]

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