Received-SPF: pass (google.com: domain of linux-crypto+bounces-4860-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
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
In-Reply-To: <ZmLZ2Zl8HUQc0jST@gondor.apana.org.au>
References: <878r02f6bv.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
 <Zlb4SHWuY9CHstnI@gondor.apana.org.au>
 <87bk4fa7dd.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
 <ZmEYiw_IgbC-ksoJ@gondor.apana.org.au>
 <875xum9t2a.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
 <ZmLZ2Zl8HUQc0jST@gondor.apana.org.au>
Date: Mon, 10 Jun 2024 18:38:49 +0530
Message-ID: <87wmmx7xni.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

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