Hi Cristian,
On Thu, Jan 21, 2016 at 12:58:55PM +0200, Cristian Stoica wrote:
> Hi Phil,
>
> These two patches add CIOCHASH ioctl that targets only hash operations. It
> is a proof of concept with the goal of improving digest performance and make
> better
> use of Linux crypto-API. Please ignore code duplication.
>
> My proposal aims to complete the design of the current cryptodev API so that
> both init-update-finalize and digest operations are available.
>
> A smart user can calibrate how much data to buffer before calling update (to
> offset
> the ioctl costs) or can decide upfront for one method or the other.
> (Openssl for example buffers the whole data and then calls cryptodev-update
> through CIOCCRYPT).
>
> In a particular machine, cryptodev/tests/speed.c reports for SHA1 0.25GB/s
> with CIOCCRYPT and
> 0.29GB/s with CIOCHASH.
>
> Please share your feedback for improving this prototype.
Thanks for providing this code, things are a bit more clear now.
So you want to eliminate the overhead of CIOCGSESSION/CIOCFSESSION for
single CIOCCRYPT operations, right? Have you considered creating a
combined struct which contains both structs session_op and crypt_op
instead of the new struct hash_op_data? Without a closer look, something
like:
| struct sscrypt_op {
| struct session_op sess;
| struct crypt_op cop;
| };
might work in combination with a new ioctl CIOCSSCRYPT ("single-shot
crypt"). This could then be used for crypto operations, as well.
Do you have benchmark data for your RFC patch 2/2? The amount of
code-duplication seems quite fair, and I doubt it's worth the effort
since it does not eliminate any context switching (or does it?).
Another concern might be low acceptance from cryptodev users. Openssl
et al. use the generic cryptodev interface as it is provided by e.g.
OCF, I'm not sure they want to implement support for a Linux-specific
version. IMO this reduces the whole concept of compatibility to the
generic cryptodev interface ad absurdum. That being said, the same
applies to CIOCGSESSINFO as well, of course.
Cheers, Phil
_______________________________________________
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel
