fbc9da5dbe
fine when a lot of different flows to be ciphered/deciphered are involved. However, when a software crypto driver is used, there are situations where we could benefit from making crypto(9) multi threaded: - a single flow is to be ciphered: only one thread is used to cipher it, - a single ESP flow is to be deciphered: only one thread is used to decipher it. The idea here is to call crypto(9) using a new mode (CRYPTO_F_ASYNC) to dispatch the crypto jobs on multiple threads, if the underlying crypto driver is working in synchronous mode. Another flag is added (CRYPTO_F_ASYNC_KEEPORDER) to make crypto(9) dispatch the crypto jobs in the order they are received (an additional queue/thread is used), so that the packets are reinjected in the network using the same order they were posted. A new sysctl net.inet.ipsec.async_crypto can be used to activate this new behavior (disabled by default). Submitted by: Emeric Poupon <emeric.poupon@stormshield.eu> Reviewed by: ae, jmg, jhb Differential Revision: https://reviews.freebsd.org/D10680 Sponsored by: Stormshield |
||
|---|---|---|
| .. | ||
| cast.c | ||
| cast.h | ||
| castsb.h | ||
| criov.c | ||
| crypto.c | ||
| cryptodeflate.c | ||
| cryptodev_if.m | ||
| cryptodev.c | ||
| cryptodev.h | ||
| cryptosoft.c | ||
| cryptosoft.h | ||
| deflate.h | ||
| gfmult.c | ||
| gfmult.h | ||
| gmac.c | ||
| gmac.h | ||
| rmd160.c | ||
| rmd160.h | ||
| skipjack.c | ||
| skipjack.h | ||
| xform_aes_icm.c | ||
| xform_aes_xts.c | ||
| xform_auth.h | ||
| xform_blf.c | ||
| xform_cast5.c | ||
| xform_cml.c | ||
| xform_comp.h | ||
| xform_deflate.c | ||
| xform_des1.c | ||
| xform_des3.c | ||
| xform_enc.h | ||
| xform_gmac.c | ||
| xform_md5.c | ||
| xform_null.c | ||
| xform_rijndael.c | ||
| xform_rmd160.c | ||
| xform_sha1.c | ||
| xform_sha2.c | ||
| xform_skipjack.c | ||
| xform_userland.h | ||
| xform.c | ||
| xform.h | ||