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

[David M. <dav...@mc...>]

Jivin Kennedy, Brendan lays it down ...
> >-----Original Message-----
> >From: David McCullough [mailto:dav...@mc...]
> >> >
> >> >Did you just want to be able to identify the HW condition that causes
> >> >this separate to an error ?
> >>
> >> Yes, we wanted to identify that the call was failing because of lack
> >of driver support rather than due to bad inputs or some such thing.
> >
> >Ok,  I backed out the change in cryptodev so that a fail is still a fail
> >at the syscall level, but we can detect this when the errno is the same
> >as the kop_status.  Saves changes the driver API in any way which is
> >kind of
> >nice to have.
> >
> >Have a look at the attached patch and see if it does what you need,  if
> >so
> >then I'll commit that.
> >
> 
> 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.

> 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 :-)

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org