Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200115060234.4mm6fsmsrryzpymi@gondor.apana.org.au>
 <9fd07805-8e2e-8c3f-6e5e-026ad2102c5a@chelsio.com> <c8d64068-a87b-36dd-910d-fb98e09c7e4b@asicdesigners.com>
 <20200117062300.qfngm2degxvjskkt@gondor.apana.org.au> <20d97886-e442-ed47-5685-ff5cd9fcbf1c@asicdesigners.com>
 <20200117070431.GE23018@gauss3.secunet.de> <318fd818-0135-8387-6695-6f9ba2a6f28e@asicdesigners.com>
 <20200117121722.GG26283@gauss3.secunet.de> <179f6f7e-f361-798b-a1c6-30926d8e8bf5@asicdesigners.com>
 <20200120093712.GM23018@gauss3.secunet.de> <b0b4ba4b-1cdd-ad0b-32e4-2bc9610ff3e1@asicdesigners.com>
In-Reply-To: <b0b4ba4b-1cdd-ad0b-32e4-2bc9610ff3e1@asicdesigners.com>
From:   Gilad Ben-Yossef <gilad@benyossef.com>
Date:   Tue, 21 Jan 2020 14:03:16 +0200
Message-ID: <CAOtvUMdfxx=-XQMv=aFFjzSnLCL3b5UuvVOMzJVc2odSCZGtXg@mail.gmail.com>
Subject: Re: Advertise maximum number of sg supported by driver in single request
To:     Ayush Sawal <ayush.sawal@asicdesigners.com>
Cc:     Steffen Klassert <steffen.klassert@secunet.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        manojmalviya@chelsio.com, Ayush Sawal <ayush.sawal@chelsio.com>,
        netdev@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 20, 2020 at 2:35 PM Ayush Sawal
<ayush.sawal@asicdesigners.com> wrote:

> As we have a crypto accelarator as device when the request is send to
> the crypto driver from esp_output ,
> the aead_request has all the fragments in its src sg and the problem
> which we are facing is when this
> src sg nents becomes greater than 15 ,15 is our crypto driver's max sg
> limit to handle the request in one shot.
>
> Does it make sense for a crypto driver to advertise the maximum amount
> of sg it can handle for a single
> request and then handling this in crypto framework while forming the
> crypto request?
>

As I maintain the driver of another crypto accelerator I sympathize
with the need but I question the proposed solution.
Consider: your specific driver is limited by the number of
scattergather entries. Another implementation might be limited
by something else such as the total overall size of the request buffer
and probably half a dozen other considerations.
Should we now be passing all this capability information to the crypto
API core? and what happens if a new driver
has a limitation in a different quality?

So no, the solution to advertise the specific capability limitation of
each implementation does not seem to be a good one.
We already have a solution to the problem - initiate a fallback TFM
request and use it if you cannot fulfill the request on your own.

I do agree however that having each implementation registering and
keeping their own fallback tfm request just for these cases has some
overhead and a redundancy.

Maybe a better solution would be to allow implementation to return to
the Crypto API core a special return value (maybe -EAGAIN?) that tells
it that although the request is a valid one, this specific
implementation cannot fulfil it and let the crypto API core do the
fallback?

It sounds like it can be simpler to the implementation providers AND
save some redundant code...

--=20
Gilad Ben-Yossef
Chief Coffee Drinker

values of =CE=B2 will give rise to dom!