Re: [Ocf-linux-users] [PATCH - EP80579 driver update patch]

[Kennedy, B. <bre...@in...>]

>-----Original Message-----
>From: David McCullough [mailto:dav...@mc...]
>
>Jivin Kennedy, Brendan lays it down ...
>> Hi Dave,
>>
>> Sorry for the slow response! I like the use of errno, but a few
>questions:
>>
>> 1. Are similar changes going to be made for DSA sign/verify
>functionality?
>
>I can do that if you want.
>
Yep, we would like those changes to be added, but the changes from my originally submitted patch are just suggestions at the end of the day ;)
 
>> 2. It seems if the failure is in the driver(as oppose to OCF) for non
>> algotithmic reasons, this will still show an algorithm fail. I think
>the
>> patch code is meant to do that, but:
>
>The "trace" from openssl should show whether it was hardware or OCF
>complaining.
>
>> 3. If the issue was because of algorithm fail (not the hardware), then
>the
>> algorithm should not be run again in software (where essentially it
>should
>> fail there for the same reason). It just slows down response time..
>
>The reason it falls back to SW is that,  at least in my experience,  the
>HW
>has limitations that the SW versions often don't.
>
>So driver regularly fail these calls because there are too many bits in
>this
>or that operand.  If that is the case I would prefer that it was handled
>in
>SW and still worked myself. Esp. since if I was using openssl without
>OCF
>it would work.
>
>Also,  for the failure case, I don't mind a true failure to be slower.
>I
>don't know of many cases where the performance of the failure case is
>critical,  but I am more than happy to consider it if you have a good
>case :-)
>

Hmm, denial of service attack based on many bogus connection attempts utilizing large keys? :)
I can only guess, however I suppose some tuning of the code is required depending on driver use cases.

I agree that in the case where the hardware cannot handle the request, the operation should be run in software.
However, I think the driver for that hardware should be able to detect any problems with input buffers etc. Also, detecting different error types can be useful in the above scenarios.

Of course, the final code changes are all up to you. If something doesn't suit enough OCF users to warrant a change, that is fair enough :)

Regards,
Brendan


--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.