On Mon, Jan 20, 2020 at 2:35 PM Ayush Sawal <ayush.sawal@xxxxxxxxxxxxxxxxx> 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!
