linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhou Wang <wangzhou1@hisilicon.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S . Miller" <davem@davemloft.net>,
	<linux-crypto@vger.kernel.org>, <linuxarm@huawei.com>,
	<linux-kernel@vger.kernel.org>,
	Kenneth Lee <liguozhu@hisilicon.com>,
	Shiju Jose <shiju.jose@huawei.com>,
	Hao Fang <fanghao11@huawei.com>
Subject: Re: [PATCH v2 2/4] crypto: hisilicon: Add queue management driver for HiSilicon QM module
Date: Sat, 2 Feb 2019 10:25:43 +0800	[thread overview]
Message-ID: <5C54FFA7.1080702@hisilicon.com> (raw)
In-Reply-To: <20190201153931.2k4yopm4akunpedg@gondor.apana.org.au>

On 2019/2/1 23:39, Herbert Xu wrote:
> On Fri, Feb 01, 2019 at 03:15:54PM +0800, Zhou Wang wrote:
>>
>>> Polling in softirq context is unacceptable.  Can't your hardware
>>> send interrupts to signal completion? What is the average speed
>>> of processing a single 1500-byte packet on your hardware?
>>
>> Our hardware supports interrupt. In fact, implementation of compress/decompress
>> interface of crypto_alg in v1 was done using interrupt:
>>
>>  compress/decompress:
>>      send task to hardware
>>      wait task finished(wait_for_completion_timeout)
>>
>>  In irq handler:
>>      complete
>>
>> However, there is get_cpu/put_cpu in scomp, wait and complete in above has to be
>> changed to poll:
>>
>>  compress/decompress:
>>      send task to hardware
>>      check if task is finished
> 
> If your hardware supports interrupts then you should be using
> the acomp interface and not scomp.

In fact, I planned to register to acomp later.

It also makes sense to use scomp if hardware engine is faster than CPU.
So how about registering to scomp firstly, then we register this engine to
acomp later?

Thanks,
Zhou

> 
> Thanks,
> 


  reply	other threads:[~2019-02-02  2:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 13:08 [PATCH v2 0/4] crypto: hisilicon: Add HiSilicon QM and ZIP controller driver Zhou Wang
2019-01-23 13:08 ` [PATCH v2 1/4] Documentation: Add debugfs doc for hisi_zip Zhou Wang
2019-01-23 13:08 ` [PATCH v2 2/4] crypto: hisilicon: Add queue management driver for HiSilicon QM module Zhou Wang
2019-02-01  5:22   ` Herbert Xu
2019-02-01  7:15     ` Zhou Wang
2019-02-01 15:39       ` Herbert Xu
2019-02-02  2:25         ` Zhou Wang [this message]
2019-02-20  4:10           ` Herbert Xu
2019-02-20  6:50             ` Zhou Wang
2019-01-23 13:08 ` [PATCH v2 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support Zhou Wang
2019-01-23 13:08 ` [PATCH v2 4/4] MAINTAINERS: add maintainer for HiSilicon QM and ZIP controller driver Zhou Wang
2019-01-29  1:19 ` [PATCH v2 0/4] crypto: hisilicon: Add " Zhou Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5C54FFA7.1080702@hisilicon.com \
    --to=wangzhou1@hisilicon.com \
    --cc=davem@davemloft.net \
    --cc=fanghao11@huawei.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=shiju.jose@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).