Re: Advertise maximum number of sg supported by driver in single request

On Mon, Jan 20, 2020 at 2:35 PM Ayush Sawal
[off-list ref] 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...

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!