ff2038a9bf
Right now, aesni_cipher_alloc does a bit of special-casing for CRYPTO_F_IOV, to not do any allocation if the first uio is large enough for the requested size. While working on ZFS crypto port, I ran into horrible performance because the code uses scatter-gather, and many of the times the data to encrypt was in the second entry. This code looks through the list, and tries to see if there is a single uio that can contain the requested data, and, if so, uses that. This has a slight impact on the current consumers, in that the check is a little more complicated for the ones that use CRYPTO_F_IOV -- but none of them meet the criteria for testing more than one. Submitted by: sef at ixsystems.com Reviewed by: cem@ MFC after: 3 days Sponsored by: iX Systems Differential Revision: https://reviews.freebsd.org/D18522 |
||
|---|---|---|
| .. | ||
| aesni | ||
| armv8 | ||
| blake2 | ||
| blowfish | ||
| camellia | ||
| ccp | ||
| chacha20 | ||
| des | ||
| libsodium | ||
| rc4 | ||
| rijndael | ||
| sha2 | ||
| siphash | ||
| skein | ||
| via | ||
| intake.h | ||
| sha1.c | ||
| sha1.h | ||