From: Kamlesh Gurudasani <kamlesh@ti.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: <davem@davemloft.net>, <linux-crypto@vger.kernel.org>,
<vigneshr@ti.com>, <j-choudhary@ti.com>
Subject: Re: [RFC] crypto: sa2ul - sha1/sha256/sha512 support
Date: Mon, 10 Jun 2024 18:38:49 +0530 [thread overview]
Message-ID: <87wmmx7xni.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <ZmLZ2Zl8HUQc0jST@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Thu, Jun 06, 2024 at 05:33:41PM +0530, Kamlesh Gurudasani wrote:
>>
>> Also, the size that can be held by one sg list [0] is 204 entries,
>> which can hold upto 800KB of data. I'm not sure if this is still true.
>> Old article. If we consider chaining we can have more data, not sure how
>> HW handles that.
>
> If it's the SG list size that's limiting you then we should look
> into allowing bigger SG lists for af_alg to be constructed.
>
Increasing the size of sg list will sove our problem to certain extent,
but not completely.
There are few scenarios where we fail,
1. If we increase the size of sg list to handle 100Mb, file size with more
than 100Mb will still fall back to init->update->finup.
SA2UL HW supports only upto 4MB max in one shot, so internally in driver we
have to break the sg list in chunks of 4MB anyway. Will take performance hit.
2. There is scenario of MSG_MORE. If the user wants to break the file
in multiple chunks because of memory limitation and then send it to
SA2UL, then again we fall back to init->update->final.
Now all this scenarios will work if we can have a 64kb of buffer
for one cra_init->init->n*update->final->cra->exit
I think this would be better solution as against increasing the sg list
size to a big value in af_alg.
With the solution of saving 64kb in context, we still won't be able to
export partial hashed state(HW limitation), but we don't even want partial hashed
states. But we can then utilize our HW at fullest as it supports
incremental hashing.
Our HW will work with init->n*updates->finup WITHOUT 64KB saved in
context, but it will FAIL the selftest with init->update->final
With the solution with 64KB(AFALG_MAX_PAGES * PAGE_SIZE) saved in
context, selftest will also PASS and then we don't have to tinker around
for the use case which use init -> update -> FINAL as standard
offloading.
Kamlesh
> 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
next prev parent reply other threads:[~2024-06-10 13:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 11:12 [RFC] crypto: sa2ul - sha1/sha256/sha512 support Kamlesh Gurudasani
2024-05-29 9:41 ` Herbert Xu
2024-06-05 12:42 ` Kamlesh Gurudasani
2024-06-06 2:01 ` Herbert Xu
2024-06-06 12:03 ` Kamlesh Gurudasani
2024-06-07 9:58 ` Herbert Xu
2024-06-10 13:08 ` Kamlesh Gurudasani [this message]
2024-06-11 3:20 ` Herbert Xu
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=87wmmx7xni.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me \
--to=kamlesh@ti.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=j-choudhary@ti.com \
--cc=linux-crypto@vger.kernel.org \
--cc=vigneshr@ti.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 read-only IMAP folder(s) and NNTP newsgroup(s).