drivers/crypto/hisilicon/Kconfig | 1 + drivers/crypto/hisilicon/hpre/hpre_crypto.c | 314 +++++++++++++++++--- drivers/crypto/hisilicon/qm.c | 4 +- drivers/crypto/hisilicon/sec2/sec_crypto.c | 62 +++- drivers/crypto/hisilicon/zip/zip_crypto.c | 52 +++- 5 files changed, 360 insertions(+), 73 deletions(-)
Support fallback for zip/sec2/hpre when device is busy.
V1: https://lore.kernel.org/all/20250809070829.47204-1-huangchenghai2@huawei.com/
Updates:
- Remove unnecessary callback completions.
- Add CRYPTO_ALG_NEED_FALLBACK to hisi_zip's cra_flags.
Chenghai Huang (1):
crypto: hisilicon/zip - support fallback for zip
Qi Tao (1):
crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware
queue unavailable
Weili Qian (1):
crypto: hisilicon/hpre - support the hpre algorithm fallback
drivers/crypto/hisilicon/Kconfig | 1 +
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 314 +++++++++++++++++---
drivers/crypto/hisilicon/qm.c | 4 +-
drivers/crypto/hisilicon/sec2/sec_crypto.c | 62 +++-
drivers/crypto/hisilicon/zip/zip_crypto.c | 52 +++-
5 files changed, 360 insertions(+), 73 deletions(-)
--
2.33.0
On Mon, Aug 18, 2025 at 02:57:11PM +0800, Chenghai Huang wrote: > Support fallback for zip/sec2/hpre when device is busy. > > V1: https://lore.kernel.org/all/20250809070829.47204-1-huangchenghai2@huawei.com/ > Updates: > - Remove unnecessary callback completions. > - Add CRYPTO_ALG_NEED_FALLBACK to hisi_zip's cra_flags. > > Chenghai Huang (1): > crypto: hisilicon/zip - support fallback for zip > > Qi Tao (1): > crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware > queue unavailable > > Weili Qian (1): > crypto: hisilicon/hpre - support the hpre algorithm fallback > > drivers/crypto/hisilicon/Kconfig | 1 + > drivers/crypto/hisilicon/hpre/hpre_crypto.c | 314 +++++++++++++++++--- > drivers/crypto/hisilicon/qm.c | 4 +- > drivers/crypto/hisilicon/sec2/sec_crypto.c | 62 +++- > drivers/crypto/hisilicon/zip/zip_crypto.c | 52 +++- > 5 files changed, 360 insertions(+), 73 deletions(-) Are you mapping one hardware queue to a single tfm object? Hardware queues should be shared between tfm objects. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
在 2025/8/25 12:36, Herbert Xu 写道: > On Mon, Aug 18, 2025 at 02:57:11PM +0800, Chenghai Huang wrote: >> Support fallback for zip/sec2/hpre when device is busy. >> >> V1: https://lore.kernel.org/all/20250809070829.47204-1-huangchenghai2@huawei.com/ >> Updates: >> - Remove unnecessary callback completions. >> - Add CRYPTO_ALG_NEED_FALLBACK to hisi_zip's cra_flags. >> >> Chenghai Huang (1): >> crypto: hisilicon/zip - support fallback for zip >> >> Qi Tao (1): >> crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware >> queue unavailable >> >> Weili Qian (1): >> crypto: hisilicon/hpre - support the hpre algorithm fallback >> >> drivers/crypto/hisilicon/Kconfig | 1 + >> drivers/crypto/hisilicon/hpre/hpre_crypto.c | 314 +++++++++++++++++--- >> drivers/crypto/hisilicon/qm.c | 4 +- >> drivers/crypto/hisilicon/sec2/sec_crypto.c | 62 +++- >> drivers/crypto/hisilicon/zip/zip_crypto.c | 52 +++- >> 5 files changed, 360 insertions(+), 73 deletions(-) > Are you mapping one hardware queue to a single tfm object? Yes, in our current implementation, each hardware queue is mapped to a dedicated tfm object. > > Hardware queues should be shared between tfm objects. > > Cheers, Thank you for your suggestion. 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. Thanks Chenghai
On Tue, Aug 26, 2025 at 09:59 AM +0800, Herbert Xu wrote: > > 在 2025/8/25 12:36, Herbert Xu 写道: >> On Mon, Aug 18, 2025 at 02:57:11PM +0800, Chenghai Huang wrote: >>> Support fallback for zip/sec2/hpre when device is busy. >>> >>> V1: >>> https://lore.kernel.org/all/20250809070829.47204-1-huangchenghai2@huawei.com/ >>> Updates: >>> - Remove unnecessary callback completions. >>> - Add CRYPTO_ALG_NEED_FALLBACK to hisi_zip's cra_flags. >>> >>> Chenghai Huang (1): >>> crypto: hisilicon/zip - support fallback for zip >>> >>> Qi Tao (1): >>> crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware >>> queue unavailable >>> >>> Weili Qian (1): >>> crypto: hisilicon/hpre - support the hpre algorithm fallback >>> >>> drivers/crypto/hisilicon/Kconfig | 1 + >>> drivers/crypto/hisilicon/hpre/hpre_crypto.c | 314 >>> +++++++++++++++++--- >>> drivers/crypto/hisilicon/qm.c | 4 +- >>> drivers/crypto/hisilicon/sec2/sec_crypto.c | 62 +++- >>> drivers/crypto/hisilicon/zip/zip_crypto.c | 52 +++- >>> 5 files changed, 360 insertions(+), 73 deletions(-) >> Are you mapping one hardware queue to a single tfm object? > Yes, in our current implementation, each hardware queue is mapped > to a dedicated tfm object. >> >> Hardware queues should be shared between tfm objects. >> >> Cheers, > Thank you for your suggestion. > > 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. > > Thanks > Chenghai Okay, we will decouple the hardware queue constraints from the number of tfm to adapt to Crypto. Thanks Chenghai > >
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, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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
On 2025/8/18 14:57, Chenghai Huang wrote: > Support fallback for zip/sec2/hpre when device is busy. > > V1: https://lore.kernel.org/all/20250809070829.47204-1-huangchenghai2@huawei.com/ > Updates: > - Remove unnecessary callback completions. > - Add CRYPTO_ALG_NEED_FALLBACK to hisi_zip's cra_flags. > > Chenghai Huang (1): > crypto: hisilicon/zip - support fallback for zip > > Qi Tao (1): > crypto: hisilicon/sec2 - support skcipher/aead fallback for hardware > queue unavailable > > Weili Qian (1): > crypto: hisilicon/hpre - support the hpre algorithm fallback > > drivers/crypto/hisilicon/Kconfig | 1 + > drivers/crypto/hisilicon/hpre/hpre_crypto.c | 314 +++++++++++++++++--- > drivers/crypto/hisilicon/qm.c | 4 +- > drivers/crypto/hisilicon/sec2/sec_crypto.c | 62 +++- > drivers/crypto/hisilicon/zip/zip_crypto.c | 52 +++- > 5 files changed, 360 insertions(+), 73 deletions(-) > Reviewed-by: Longfang Liu <liulongfang@huawei.com> Thanks.
© 2016 - 2025 Red Hat, Inc.